Consuming MongoDB from a Snap

[John Meinel]

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" <felipe.reyes at canonical.com> wrote:

> On Fri, 23 Jun 2017 00:09:14 +0000
> Andrew Wilkins <andrew.wilkins at canonical.com> wrote:
>
> > On Fri, Jun 23, 2017 at 7:47 AM Menno Smits
> > <menno.smits at canonical.com> 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 at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20170727/4be27604/attachment.html>