Consuming MongoDB from a Snap
Felipe Reyes
felipe.reyes at canonical.com
Wed Jul 26 14:51:36 UTC 2017
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
More information about the Juju-dev
mailing list