Interim plan to move away from the mongo tarball

[Mark Ramm]

On 03/27/2013 06:58 AM, Gustavo Niemeyer wrote:
> 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.

I think it is perfectly reasonable to tie down Juju's control node(s) to 
a specific series.   We do not expect charms to automatically work on 
all series, so I don't see why we should do the same for bootstrap node 
type internal services.

This slightly increases the the work require to handle upgrades (though 
only when you want to upgrade a juju version that uses one series to a 
newer version that uses a new series) and I think that's a both a 
solvable problem, and one that we can afford to solve later.

--Mark Ramm