Client Registration issue - 'Maximum number of computers pending approval reached'

This may actually be related to landscape-server returning "maxiumum number of computers pending approval reached".

I think this bug should be against both landscape-server and landscape-client. The server side needs a tweak to allow as many pending approvals as you have licenses in stock for a large cloud deployment.

Secondarily, landscape-client needs to retry when it receives this return from landscape-config.

Restarting landscape-client (via systemctl): landscape-client.service.
('Maximum number of computers pending approval reached. ', 'Login to your Landscape server account page to manage pending computer approvals.')

Instead of accepting batches of 20, wouldn't it be simpler to just (temporarily) set a registration-key so clients don't need to be manually approved in the UI?

@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.