Re: Consuming MongoDB from a Snap
On 26/07/17 15:51, Felipe Reyes wrote: > Some users run the controller in fairly big bare metal machines (e.g. > 128G of RAM, I've seen even bigger controllers) and it won't be easy for > them to have an extra machine to setup a new controller and run model > migration, if their controller is HA then 3 spare machines are > needed, this is hard to justify. Could LXD solve that problem? Seems like having A/B containers in each of those machines would be fine. The total amount of work isn't growing, it's just shifting from one codebase to the next. So, the three machines each get two containers, the Juju controller is spread across three A controllers, the new one goes into the B controllers, and migration essentially takes place on the same hardware. Mark -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Consuming MongoDB from a Snap
On Fri, 23 Jun 2017 00:09:14 + Andrew Wilkins wrote: > On Fri, Jun 23, 2017 at 7:47 AM Menno Smits > wrote: > > > We've had some discussion this week about whether Juju could use > > MongoDB from snap instead of a deb. This would make it easier for > > Juju to stay up to date with the latest MongoDB releases, avoiding > > the involved process getting each update into Ubuntu's update > > repository, as well as giving us all the other advantages of snaps. > > > > Two concerns were raised in this week's tech board meeting. > > > > *1. Does snapd work on all architectures that Juju supports?* > > > > The answer appears to be "yes with some caveats". For xenial > > onwards there are snapd packages for all the architectures the Juju > > team cares about. > > Ah, I thought the question was rather whether or not the mongo snap > existed for all of those architectures. I don't think it does. IIANM, > the snap comes from > https://github.com/niemeyer/snaps/blob/master/mongodb/mongo32/snapcraft.yaml, > which (if you look at the "mongodb" part, appears to only exist for > x86_64). So we would need to do some work on that first. > > > >https://packages.ubuntu.com/xenial/snapd > > > > For trusty only amd64, armhf and i386 appear to be supported. > > > >https://packages.ubuntu.com/trusty-updates/snapd > > > > This is probably ok. I think it's probably fine to start saying > > that new Juju controllers, on some architectures at least, need to > > be based on xenial or later. > > > > Since the controller machine isn't designed for workloads, it seems > fine to me to restrict them to latest LTS. > > One issue would be upgrades: we would either have to continue > supporting both snaps and debs for mongodb, or we would have to > disallow upgrading from a system that doesn't support snaps. That > would OK as long as there are no workloads on the controller, as we > could use migration. Some users run the controller in fairly big bare metal machines (e.g. 128G of RAM, I've seen even bigger controllers) and it won't be easy for them to have an extra machine to setup a new controller and run model migration, if their controller is HA then 3 spare machines are needed, this is hard to justify. -- Felipe Reyes Software Sustaining Engineer @ Canonical # Launchpad: ~freyes | IRC: freyes -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Consuming MongoDB from a Snap
On Wed, 26 Jul 2017 15:58:30 +0100 Mark Shuttleworth wrote: > On 26/07/17 15:51, Felipe Reyes wrote: > > Some users run the controller in fairly big bare metal machines > > (e.g. 128G of RAM, I've seen even bigger controllers) and it won't > > be easy for them to have an extra machine to setup a new controller > > and run model migration, if their controller is HA then 3 spare > > machines are needed, this is hard to justify. > > Could LXD solve that problem? > > Seems like having A/B containers in each of those machines would be > fine. The total amount of work isn't growing, it's just shifting from > one codebase to the next. > > So, the three machines each get two containers, the Juju controller is > spread across three A controllers, the new one goes into the B > controllers, and migration essentially takes place on the same > hardware. Sounds like a good option, specially since this may open the door to have faster rollbacks, something we achieve today using VM snapshots and/or "juju backups". We just need to be careful to not assume the machine will have enough resources to have both containers (jujud and mongod in them specifically) running at the same time. -- Felipe Reyes Software Sustaining Engineer @ Canonical # Launchpad: ~freyes | IRC: freyes -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Consuming MongoDB from a Snap
I just wanted to note that some of the reason for 128GB was because 2.0 and 2.1 did leak memory over time. And if you have a leak you will always eventually run out. In 2.2 we've fixed all the ones we've found so far and we're actively doing some performance measuring to give better guidelines. (If you are running X machines Y units you need a machine with A cores and B memory.) There are a lot of different ways to stress Juju (lots of small models, one giant model, etc) and many performance numbers are soft (command X gets slower, but doesn't fail, at what point do we consider it unusable). All this to say, we've run ~2000 units against 16GB of memory. There really shouldnt be a need to go to 128+ in the future. Current results show us to be more CPU constrained (at least during deploy, etc) on normal RAM vs CPU ratios. John =:-> On Jul 26, 2017 16:51, "Felipe Reyes" wrote: > On Fri, 23 Jun 2017 00:09:14 + > Andrew Wilkins wrote: > > > On Fri, Jun 23, 2017 at 7:47 AM Menno Smits > > wrote: > > > > > We've had some discussion this week about whether Juju could use > > > MongoDB from snap instead of a deb. This would make it easier for > > > Juju to stay up to date with the latest MongoDB releases, avoiding > > > the involved process getting each update into Ubuntu's update > > > repository, as well as giving us all the other advantages of snaps. > > > > > > Two concerns were raised in this week's tech board meeting. > > > > > > *1. Does snapd work on all architectures that Juju supports?* > > > > > > The answer appears to be "yes with some caveats". For xenial > > > onwards there are snapd packages for all the architectures the Juju > > > team cares about. > > > > Ah, I thought the question was rather whether or not the mongo snap > > existed for all of those architectures. I don't think it does. IIANM, > > the snap comes from > > https://github.com/niemeyer/snaps/blob/master/mongodb/ > mongo32/snapcraft.yaml, > > which (if you look at the "mongodb" part, appears to only exist for > > x86_64). So we would need to do some work on that first. > > > > > > >https://packages.ubuntu.com/xenial/snapd > > > > > > For trusty only amd64, armhf and i386 appear to be supported. > > > > > >https://packages.ubuntu.com/trusty-updates/snapd > > > > > > This is probably ok. I think it's probably fine to start saying > > > that new Juju controllers, on some architectures at least, need to > > > be based on xenial or later. > > > > > > > Since the controller machine isn't designed for workloads, it seems > > fine to me to restrict them to latest LTS. > > > > One issue would be upgrades: we would either have to continue > > supporting both snaps and debs for mongodb, or we would have to > > disallow upgrading from a system that doesn't support snaps. That > > would OK as long as there are no workloads on the controller, as we > > could use migration. > > Some users run the controller in fairly big bare metal machines (e.g. > 128G of RAM, I've seen even bigger controllers) and it won't be easy for > them to have an extra machine to setup a new controller and run model > migration, if their controller is HA then 3 spare machines are > needed, this is hard to justify. > > -- > Felipe Reyes > Software Sustaining Engineer @ Canonical > # Launchpad: ~freyes | IRC: freyes > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju-dev > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
