Endpoints trials + MAAS charms
dmitrii.shcherbakov at canonical.com
Mon Nov 27 08:09:55 UTC 2017
This is an interesting approach, thanks for taking a shot at solving this
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
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.
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).
"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.
Field Software Engineer
IRC (freenode): Dmitrii-Sh
On Sun, Nov 26, 2017 at 4:14 AM, James Beedy <jamesbeedy at gmail.com> 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
> 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/
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Juju