Consuming MongoDB from a Snap

Mark Shuttleworth mark at ubuntu.com
Mon Jul 31 08:24:00 UTC 2017


On 31/07/17 01:34, Michael Hudson-Doyle wrote:
> On 23 June 2017 at 11:47, Menno Smits <menno.smits at canonical.com
> <mailto: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.
>
>  
> Given that juju-mongodb 3.2.15 has been sitting in the xenial review
> queue for three weeks and now 3.2.16 has come out...
>
> It is clear that the SRU process is not really a good fit for getting
> new versions of mongodb to juju controllers in the wild. What else
> could work? A PPA perhaps, but that has some of the same offline story
> problems as snaps, you'd need to include the PPA in whichever archive
> mirror the controller nodes are configured to use. You could use a
> stream-based approach similar to how jujud is installed, I guess?
> Probably best to ship a deb or a snap in the stream though, you don't
> want to be re-implementing the upgrade support and process management
> stuff yourself if you don't have too. (Shipping a deb you'd need to so
> some worrying about how easy it is to build per-series debs or build a
> mongodb that is statically linked enough to work across different
> series -- don't really know how much work either of those would entail).

At some level it's weird to express something as a deb which only exists
to be used by one thing - Juju. The deb dependency system is really good
for things that end up being widely useful, but not great for something
like juju-mongodb. It has always felt like an awkwardness that would be
better managed internally to the jujud package. There are attendant
costs - security updates etc. But we already have duplication in that we
have a whole copy of mongodb. Where that copy lives is not material, it
should therefor live where it is most convenient for the people who use
it, which is jujud.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20170731/3af3d377/attachment.html>


More information about the Juju-dev mailing list