Endpoints trials + MAAS charms

Mon Nov 27 13:31:24 UTC 2017

It does seem like Juju operating the LXD provider, but spanning multiple
machines would be an answer. I do believe that LXD itself is introducing
clustering into their API in the 18.04 cycle. Which would probably need
some updates on the Juju side to handle their targeted provisioning (create
a container for maas-postgresql on the 3rd machine in the LXD cluster).
But that might get you out of manual provisioning of a bunch of machines
and VMs to target everything.
We're certainly not at a point where you could just-do-that today.
I can also see that it took a few attempts to get there (the last machine
is #40 :)
John
=:->

On Mon, Nov 27, 2017 at 5:17 PM, James Beedy <jamesbeedy at gmail.com> wrote:

> Dmitrii,
>
> Thanks for the response.
>
> When taking into account the overhead to get MAAS deployed as charms, it
> definitely makes the LXD provider method you have described seem very
> appealing. Some issues I've experienced trying to get MAAS HA deployed are
> such that it seems like just a ton of infrastructure is needed to get MAAS
> HA standing using the manual provider deploying the MAAS charms. You have
> to provision/maintain the manual Juju controller cluster underneath MAAS,
> just to have MAAS .... ugh
>
> I found not only the sheer quantity of servers needed to get this working
> quite unnerving, but also the manual ops I had to undergo to get it all
> standing #snowflakes #custom.
>
> I iterated on this a few times to see if I could come up with something
> more manageable, and this is where I landed (brace yourself) [0]
>
> What's going on there?
>
> I created a model in JAAS, manually added 3 physical hosts across
> different racks, then bootstrapped 4 virtual machines on each physical host
> (1 vm for each postgresql, maas-region, maas-rack [1], juju-controller
> (juju controllers for maas provider, to be checked into maas)) on each host.
>
> I then also added my vms to my JAAS model so I could deploy the charms to
> them (just postgresql and ubuntu at the time - the MAAS stuff got manually
> installed and configured after the machiens had ubuntu deployed to them in
> the model).
>
> (ASIDE: I'm seeing I could probably do this one better by combining my
> region and rack controller to the same vm, and colocating the postgresql
> charm with the region+rack on the same vm, giving me ha of all components
> using single vm on each host.)
>
> I know there are probably a plethora of issues with what I've done here,
> but it solved a few primary issues that seemed to outweigh the misuse.
>
> The issues were:
>
> 1) Too many machines needed to get MAAS HA
> 2) Chicken or egg?
> 3) Snowflakes!!!
> 4) No clear path to support MAAS HA
>
> My idea behind this was such that by using JAAS I am solving the chicken
> or the egg issue, and reducing the machines/infra needed to get MAAS HA.
> Deploying the MAAS infra with Juju eliminates the snowflake/lack of
> tracking and chips at the "No clear path to support MAAS HA".
>
> Thanks,
>
> James
>
> [0] http://paste.ubuntu.com/25891429/
> [1] http://paste.ubuntu.com/26058033/
>
> On Mon, Nov 27, 2017 at 12:09 AM, Dmitrii Shcherbakov <
> dmitrii.shcherbakov at canonical.com> wrote:
>
>> 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 <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 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
>>> Juju at lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20171127/d390aecf/attachment.html>