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

Bug #1764882 reported by Miguel Meneses
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Landscape Charm

Bug Description

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.

tags: added: canonical-bootstack
Revision history for this message
Drew Freiberger (afreiberger) wrote :

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

summary: - Additional machines are not automatically registered when changing to a
- license that allows a greater number of machines
+ Client Registration issue - 'Maximum number of computers pending
+ approval reached'
description: updated
description: updated
Revision history for this message
Simon Poirier (simpoir) wrote :

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?

Revision history for this message
Drew Freiberger (afreiberger) wrote :


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.

Changed in landscape-charm:
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.