Improve migration of rack controllers

[Nick Niehoff]

The operation of moving a rack controller between region controllers is currently a supported operation.

The supported method of doing this is to first delete the rack controller from a region controller and then rerunning the maas-rack register command on the rack controller.

To delete the rack controller from a region controller via the web interface, navigate to the "Controllers" page, select the rack controller wishing to be removed, and issue the delete action in the dropdown.

To delete the rack controller from a region controller via the cli, issue the command:

> maas $profile rack-controller delete <system_id>

Where the system_id for the rack controller can be found in the output of:

> maas $profile rack-controllers read

You would then follow the register procedures to register the rack controller with another region controller.

However, if you are removing the rack-controller from the region controller and that rack controller is the primary rack controller serving dhcp this command will fail unless the force=true parameter is passed to the commandline. You typically will not want to force the removal of a rack controller in this case as dhcp will no longer be offered for the vlans it is servicing dhcp requests for. Additionally, if the rack controller is also serving pods - they will require the use of the force option as well and the pods will be removed if the rack controller in question is only a rack controller (if it is a region+rack controller, the pods will remain).

This request would be to provide a method not requiring forceful removal of the rack controller.

This issue is directly related to [1] in which may also address this issue.

[1] https://bugs.launchpad.net/maas/+bug/1888718

[khb (khbkhb)]

It is not simply the "forceful" removal which is a sticking point for us. The intended use case is where we would like to be able to move all of a rack's managed machines from one region to another (temporarily or permanently). Ideally, this would be completely handled by MAAS, so something like:

maas $ROLE rack-transfer $RACK to $REGION

and MAAS would handle all of the details (dhcp leases, KVM pods, etc.) seamlessly. If the rack controller is truly stateless, this could be a region to region operation. If there remains some local state, it might be better viewed as downloading all of the rack state from the region, degreistering with the origin region and registration (perhaps a special mode, so that the region knows to copy up all the relevant state). Where this is the primary (or only) rack controller, appropriate pause/locking operations should take place (if operations are ongoing and can be completely handled by the rack controller they could continue operations which can't should be automatically paused, restarted or the migration deferred until pending operations are completed (and new operations are queued up, etc.).

[Alberto Donato (ack)]

Hi,

thanks for the detailed description.

Since we're currently using Discourse (https://discourse.maas.io/) for tracking and discussing feature request, would you mind making a post there in the "Features" category about this?