Comment 3 for bug 1764882

@simpoir

There's a race condition in place when deploying a new cloud in this fashion:

Deploy cloud resources including landscape-client with default "standalone" account with no registration key config with url and ping-url set to the eventual landscape URL.

Deploy the LMA resources which include landscape-server, landscape-rmq, postgres, and landscape-haproxy.

At this point, the clients register without a key because they've been configured to talk to landscape and it's now responding during update-status attempts to register.

You then initialize an account in Landscape and set up a registration key.

You run juju config to set the registration key on all landscape-clients, but they're already registered, so the updated registration-key doesn't grant the clients access because they're already pending.

There are a few ways we can work around this.

1. Don't deploy/configure landscape-client until landscape is deployed (this is difficult when deploying landscape-server and landscape-client within the same bundle).
2. Provide an action on landscape-server charm to approve all pending registrations that can be run after the model settles.
3. Provide relation to landscape-client that passes the url/ping_url/registration-key for the default account
4. Provide a nagios/alerting system check that notifies operators about pending computer registrations. (I've got other monitoring suggestions as well, and will add them as a new RFE bug.)

I would regard #4 (monitoring/alerting) as a requirement for operating Landscape at-scale successfully.

Option 3 has been attempted in the past, but when running multiple landscape-server instances with haproxy in front of landscape, the relation data doesn't provide the HA IP for the service in the relation, and may end up pointing a client to a standby unit's URL.

Option 1 is not aligned with the goals of being able to deploy bundles as the only action to stand up an entire environment. Option 2 provides at least a juju-client method to workaround the issues presented by the registration-key race condition of the new cloud deployment use case.