Interim plan to move away from the mongo tarball

[Gustavo Niemeyer]

On Tue, Mar 26, 2013 at 11:26 AM, James Page <james.page at canonical.com> wrote:
> The agreed version of MongoDB (currently 2.2.3) will be backported to
> precise and quantal; its still not in main so fixes right now would be
> driven through the Ubuntu server team (rather than from security team
> for example) - but they should be fixes, not upgrades :-).  I'm hoping

That's exactly my concern. So what's the plan to maintain a single
version across all of the releases?  Let's say we want to use 2.4 by
13.10.. how will we get 2.4 into Precise?

> I think this is fine; looking at the simplicity of the mongodb upstart
> script you should be able to maintain a separate mongodb configuration
> and data directories for Juju.  That way you take the compiled
> binaries from the package (with all the goodness that gets you re
> security updates etc..) and the configuration etc is outside of the
> package and not touched.
>
> This also allows you to restart the juju mongodb when you want to,
> rather than when apt upgrades the package.  This is kinda what ceph
> does automatically - the package installs the binaries, its up to the
> admin to restart the services.

Both of these sound like a good idea.

>> The long term maintenance also feels tricky. We won't be able to
>> use a new MongoDB release without retrofitting the package into
>> all supported releases, which extends for a period of 5 years in
>> LTSes.
>
> Backporting of new versions well help this but realistically after 2-3
> years of an LTS I suspect most Juju users will be running on the next
> LTS anyway; so we should probably be agreeing some sort of two year
> fix on MongoDB version at 14.04.

It's not clear to me what this means. The LTS has a lifespan of 5
years. I believe we should support this, which means that the release
of MongoDB we use 4.5 years after the LTS was released must still run
on that LTS.


gustavo @ http://niemeyer.net