What I want to do is: enable-ha --to lxd:0 where 0 is already deployed to another model in the MAAS cloud
Long, rambling stream-of-consciousness begins:
I had a wonderful IRC banter with @wallyworld, blahdeblah and QthePirate regarding this last night, and I wanted to put it down in here partly to straighten out my own thoughts, and also to understand what I should and shouldn’t be doing, as I’m almost certainly straying off-track here.
DISCLAIMER: My cluster has several ‘pet’ resources which are unavoidable as they’re specialized hardware which whilst able and required to carry regular workloads(they have a very high capacity), are frequently but not constantly needed to perform their own specialized tasks - a future state is that elastic migration of units from and to these resources can be done on a schedule, which is not my focus for this question, as it requires me to get a few other pieces of the puzzle straight first, and would likely be dealt with by a second-tier orchestrator like K8s or clustered lxd.
I have a MAAS cloud Juju controller. It’s on a KVM that was manually deployed to a host I’m trying to decommission. The host has several other workloads with connected dependencies I’ll be manually unpicking as I go, and rebuilding within the awesome Juju platform with as little ‘pet’ configuration as possible.
Migrating to Juju-managed resources:
Based on the docs and discussions it seems the clean way to begin is by migrating the Juju controller to the target MAAS cluster. The clean way to do this appears to be by using enable-ha, scaling out to the target, then removing the controller unit from the old node.
The difficulty I’m experiencing is this: The controller would preferably live in an lxd container - and any scaling would be to new containers on existing machines or existing containers within the MAAS cloud, as a safe assumption is that all machines within the MAAS cloud are currently checked out to other models, but available to carry more units.
What I want to do is: enable-ha --to lxd:0 where 0 is already deployed to another model in the MAAS cloud.
Options I’m aware of are:
enable-ha --to 1/lxd/0. This doesn’t work - adding an ssh: machine fails “
ERROR machine is already provisioned”. This method if it worked would also be at the expense of the MAAS cloud functionality, which I’d be reluctant to give up.
Use a KVM pod instead. I know this would work, but the KVM layer is something I need to minimize use of, as it’s frequently used by ‘pet’ workloads that require a lot of resources, and additionally some of the machines that have the highest available capacity for compute resources simply aren’t physically able to carry KVM at all.
If you’re still reading, thank you for your time and patience - a beverage of your choice is at my expense if we meet.
You folks are awesome and are building what is unquestionably the future of SDI automation.