Relation between Landscape client and server should include config info

Totally agree. In fact I already started working on this, so expect some patches soon.

Note that according to https://help.landscape.canonical.com/LDS/SSL we CANNOT use a self signed cert - we have to use a self signed CA and then make a cert from that. The charm does none of this and so when we want to make a fresh environment we wind up ditching the cert created by the charm.

@Xav,

FWIW, here are steps I used to register clients in previous deployments:

$ landscape_ip=$(juju run \
     --application haproxy 'unit-get private-address')
$ landscape_crt=$(juju run \
     --application haproxy \
     'sudo openssl x509 -in /var/lib/haproxy/default.pem' | base64)
$ juju config landscape-client \
    account-name=standalone \
    url="https://${landscape_ip}/message-system" \
    ping-url="http://${landscape_ip}/ping" \
    ssl-public-key="base64:${landscape_crt}"

It worked at least in February 2017.

What I had to do in this instance, though I didn't test your approach:

    - Create a CA, and make a cert from that rather than a straight
      self-signed cert. https://help.landscape.canonical.com/LDS/SSL is accurate.
    - Add the cert itself and key to the landscape-server and landscape-haproxy
      charm config, base64 encoded.
    - Add the CA cert to the landscape-client charm, base64 encoded and
      prefixed with base64:
    - Manually go to the haproxy box and restart haproxy.

The fact remains, the charm should do all of this. If we need a CA, then the docs are correct and the charm won't ever work. If we can work with self-signed certs, then the charm needs the fix Ante has put together, and the docs need to be fixed as well.

After investigation, solution does not really require creating CA.

I concur that Nobuto's approach is best. I've been struggling with any other method of making this relation work and what I've found is that relating landscape-client to landscape-server:registration is that if you have landscape-server in HA mode, the registration code pins you to one of the landscape-servers and half of them work great and half die on the vine.

This relation must also go hand-in-hand with a relation to the haproxy service for url, ping-url, and ssl-public-key as is noted in comment #3.

This extra step is not needed if you register an SSL cert for an externally queryable FQDN beforehand, nail an IP in MAAS for the HAproxy unit to match the externally queryable name (or use the maas auto-dns name), and place the ca and full external DNS name for the landscape-haproxy units into the landscape-client configs.

I've subscribed field-medium here.

https://code.launchpad.net/~cpe-consulting/landscape-charm/client-relation/+merge/322015 is a fork which is used on a number of clouds in order to address this issue, although there are inconsistent results with some landscape-client units remaining with the 'Need computer-title and juju-info to proceed' status.