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

[Miguel Meneses]

Recently We changed the license, and that was high number of landscape-client units which not been registered and did not intended to register after license change. The landscape-client charm sits in maintenance mode with status message: Need computer-title and juju-info to proceed. We've noticed that the first 20 systems will register fine when configured properly.

Workaround is to accept the pending approvals in landscape-server Web UI and then run 'landscape-config --silent' across landscape-clients in maintenance mode to register the next batch of 20. In a cloud of >50 landscape-client units, this is markedly tedious.

[Drew Freiberger (afreiberger)]

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.')

[Simon Poirier (simpoir)]

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?

[Drew Freiberger (afreiberger)]

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