Interim plan to move away from the mongo tarball

[James Page]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 26/03/13 14:50, Gustavo Niemeyer wrote:
> 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?

Right now we have not agreed a plan to maintain a single version
across all Ubuntu releases; I've committed to providing 2.2.3 with SSL
enabled as a backport for precise and quantal which gets us out of the
immediate hole.

We need to discuss long term support for MongoDB in more detail (see
below).

[...]
>>> 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.

Thinking about this in a bit more detail, I think we have two routes
we could follow:

1) Go Juju supports multiple major versions of MongoDB

For example, 2.2 and 2.4 would be supported versions which we test
against; Juju can then be used with 2.2 in 12.04, 12.10 and 13.04 and
2.4 in 13.10+.  This means we leverage all of the existing Ubuntu
processes with regards to SRU's, security updates etc...

2) We spawn a separate mongodb-juju package

Benefit of this is that its not the main distro package; its
specifically for Juju so we can maintain more distinct control over it
for updates etc..

We would need todo the associated groundwork but if we followed this
route it may be possible to get a general release exception to allow
us to update this package in released versions of Ubuntu; so we could
provide 2.4, 2.6 upgrades into released versions of Ubuntu.

Drawbacks; well its an extra package duping something already in the
archive; its only just part of the picture as dependencies might also
need upgrading as well; its overhead as we will need to test upgrades
on numerous Ubuntu releases at some point in the future.

I think we are currently on route to 1) - if we want to move to 2)
then we have more upfront and ongoing work todo to get agreement from
the various teams that would be involved in making that happen.

- -- 
James Page
Technical Lead
Ubuntu Server Team
james.page at canonical.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBCAAGBQJRUs3wAAoJEL/srsug59jDWlQQAM5PA8M/CDAq/oXw4Em3pRt2
iI/6tjEXmpVVFQCb1cMAJHqFrt7MTNsjdD1kfjH5Xk3ZdLO2xevlUV0XnToBNFtG
nKpLnGmupRpIrXnLXPXuTdxBq6Hqn9Nj8h7TQOE8i5uyly+qDSZm5YM0T8EFzqP1
6zxCwRlrT9DJ8OUB94bUPmDwQEFZOZ2GwMQdGSQXbGfDEj/Jga7WvjnYyKFywRhY
1i0qRkPuqMRVyoRTGY+dLr6954r7Q+Q9BsFzgQVnLut7jKYRSVYNX1xh47j4syVs
YRS3GnUyoxzauYrJxX6ISpEU4E2ilNUDcoqRF595AkL8WbZDFH3SSL14VqS/kFfi
17MSmR7dSAPjd7Hl+O7gHu2qFq5LSO9jpOVT2GCk2j4+taga+wfNCXGWtoaJXcUY
uyQ056SETHHVtQL64YUZDC+xSgZYiWVsRn3lQcS/yyWivpmcBqw2WXAk5VFWaxEj
FjvtbS6r0zkQolyJ5pX1Pz8172KXhjDCm9rydOCnmmVEUTi8w2zS7Suh+m/oY+au
9OJGfP4P6RXooCrmbJWSeT4aR3ADUKXlCuLKDz9y58zxDOk15eBBQNXNfxQuHiVr
IAaUXTYBUdoSPTBq5WKwC4aD3e0rDw/eNYK1oZeh08FreVqUScS74Guzsb7ce914
A/ge8+7sLLUZfFEWSzMm
=8VW5
-----END PGP SIGNATURE-----