Cannot migrate models containing only manual machines between cloud based controllers in different clouds
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Triaged
|
High
|
Unassigned |
Bug Description
IS run many juju models for services we run for the business using shared controllers deployed into our production clouds.
We're currently migrating workloads to our newer production cloud, and in most cases this involves redeploying into fresh models, as of course we need to redeploy the service instances to the new cloud too.
We do also have a number of models that only contain manual machines, eg those added with add-machine ssh:, examples being our company VPN servers, or high bandwidth archive servers.
These seem an ideal candidate for model migration, as the instances themselves are on bare metal and do not need to be moved or redeployed.
We're unable to just migrate the models however, as the model itself is defined as in cloud "prodstack-45" which doesn't exist on the prodstack-5 based controller, meaning the migration fails:
"migrating: aborted, removing model from target controller: model data transfer failed, failed to import model into target controller: updating cloud credentials: cloud "prodstack-45" not found (not found)"
Adding the old cloud to the new controller, so making it multi-cloud aware would likely allow us to migrate the model, but when we decommission prodstack-45 at year end we have concerns for implications of a dead cloud and dead credentials to the health of the juju controllers.
It would seem better to be able to disassociate a model containing only manual machines such that they were independent of openstack cloud and could be migrated cleanly?
Changed in juju: | |
milestone: | 2.9-next → none |
model migration can be overly fussy about ensuring that once migrated, the new controller can access the resources which have come across eg the credential check that is done compares the content not the actual functionality. And yes, manual machines are separate from the nominal cloud associated with the model so we should be able to do something better than just rejecting things outright.