Oooooo .... possibly I'm on to something (last item/very bottom) https://imgur.com/a/6Wyd0
On Mon, Nov 27, 2017 at 5:53 AM, James Beedy <jamesbe...@gmail.com> wrote: > | I can also see that it took a few attempts to get there (the last > machine is #40 :) > > It was a trying process to say the least - possibly I am one of few users > who would stick around to see it through..... which is actually great > because it creates a market for people to provide the service of providing > MAAS! > > At least, with the MAAS charm, you can 1) create and add your vms, 2) juju > deploy bundle, 3) profit. > > Instead of deploy #40 which is probably #100 by now + tears + 10 trips to > the datacenter + <add unpleasantry here> > > > On Mon, Nov 27, 2017 at 5:31 AM, John Meinel <j...@arbash-meinel.com> > wrote: > >> 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 <jamesbe...@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.shcherba...@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 <jamesbe...@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@lists.ubuntu.com >>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>>> an/listinfo/juju >>>>> >>>>> >>>> >>> >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/juju >>> >>> >> >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju