Interim plan to move away from the mongo tarball

[Gustavo Niemeyer]

On Wed, Mar 27, 2013 at 7:46 AM, James Page <james.page at canonical.com> wrote:
> 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...

The problem with this is that we can't use a feature from 2.4 until
the earliest supported release of Ubuntu upgrades to it, and we have
to pray for the gods of compatibility to keep the driver and the
database talking to each other across whatever span we go through.

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

This sounds like a more manageable situation. There's still something
missing, though. Imagine the following scenario:

1) 13.04 ships with MongoDB 2.2 and juju 2.0
2) 13.10 ships with MongoDB 2.4 and juju 4.0

We want to use features from MongoDB 2.4 in juju 4.0, so we upgrade
juju-mongodb in 13.04 to 2.4 as well so we can use them. What happens
with people in 13.04 that are using juju 2.0 still?  If we upgrade
juju in 13.04 to 4.0 so it can talk to MongoDB 2.4, what happens with
live environments?

The real underlying problem is not actually that hard, though. We can
easily build the necessary tooling in 13.10 that makes 13.10 able to
manage a 13.04 installation. What is necessary is to split the notion
of what ships in the distribution from what is usable in the
distribution, so we can get hold of these release from the future.

That said, I think there's an easy way out that avoids most of that
confusion by dropping some functionality that doesn't seem critical at
this point: restrict juju so that bootstrapping only happens on the
specific series that the respective juju in use was deployed on. This
means the juju being deployed will necessarily get to talk to a
mongodb it's happy with.

Note that, as long as we continue with the out-of-band juju binaries,
this doesn't prevent cross-series deployments. It just means that the
master nodes will have a specific series, which feels like a fair call
in exchange for less work on our side.


gustavo @ http://niemeyer.net