Hi James, This is an interesting approach, thanks for taking a shot at solving this problem!
I thought of doing something similar a few months ago. The problematic aspect here is the assumption of having a provider/substrate already present for MAAS to be deployed - this is the chicken or the egg type of problem. If you would like to take the MAAS charm route, manual provider could be used with Juju to do that with pre-created hosts (which may be containers/VMs/hosts all in a single model with this provider, regardless of how they were deployed). There would be hosts for a Juju controller(s) and MAAS region/rack controllers in the end. If you put both Juju controller and MAAS into containers, it gives you some flexibility. If you are careful, you can even migrate those containers. Running MAAS in an unprivileged container should be perfectly possible https://github.com/CanonicalLtd/maas-docs/issues/700 - I am not sure that the instructions that require a privileged container with loop devices passed to it are relevant anymore. An alternative is to use the lxd provider (which can connect to a remote daemon, not only localhost) but this is only one daemon per provider. For HA purposes you would need several LXDs on different hosts and for this provider to support network spaces because you may have MAAS hosts located in different layer 2 networks with different subnets used. Cross-model relations could be used to have a model per LXD provider but I am not sure this is the best approach - units would be on different models with no shared unit-level leadership. https://github.com/juju/juju/tree/develop/provider/lxd With the new LXD clustering work it might be possible overcome this limitation as well. I would assume LXD clustering to work on a per-rack basis due to latency constraints while with MAAS in a data center you would surely place different region controllers and rack controllers on different racks (availability zones). https://insights.ubuntu.com/2017/10/23/lxd-weekly-status-20-authentication-conferences-more/ "Distributed database for LXD clustering" If, by the time of LXD clustering release, there was support for availability zones it would have solved the problem with a single control plane for a Juju provider in the absence of MAAS. An alternative to the above is just usage of bootstrap automation to set up MAAS and then usage of Juju with charms for the rest of what you need. Best Regards, Dmitrii Shcherbakov Field Software Engineer IRC (freenode): Dmitrii-Sh On Sun, Nov 26, 2017 at 4:14 AM, James Beedy <[email protected]> wrote: > Hello all, > > I've got an HA maas setup at the datacenter, I had some trouble getting > the full HA bits super solid in the past, and thought it appropriate to try > charming up the new 2.3 MAAS snaps to see if I could make my life a bit > easier going forward. > > I just took a quick first swipe at this, so please excuse the lack of any > tests. > > I'm hoping I can kill 2 birds with 1 stone here by a) possibly getting > some feedback from @cory_fu on how I'm using the new Endpoints stuff > landing soon in reactive (and disseminate that feedback so others will be > in the know too), and b) possibly someone from @MAAS team might give me a > nod if the steps I've taken here look to be moving in the right direction? > > # Interface and layer > interface-maas: https://github.com/jamesbeedy/interface-maas > layer-maas: https://github.com/jamesbeedy/layer-maas > > # MAAS charm > charmstore: https://jujucharms.com/u/jamesbeedy/maas/8 > > # Sample bundle > sample bundle: http://paste.ubuntu.com/26046016/ - (only for reference, > this won't actually deploy) > > # juju status > `juju status`: http://paste.ubuntu.com/26045880/ > > > Thanks, > > James > > > -- > Juju mailing list > [email protected] > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju > >
-- Maas-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/maas-devel
