Interim plan to move away from the mongo tarball

[Gustavo Niemeyer]

On Tue, Mar 26, 2013 at 1:55 AM, David Cheney
<david.cheney at canonical.com> wrote:
> Yes, but by not using apt, we are inventing a new way of distributing
> binaries, especially to customers who choose to place their Juju
> installations 'off the grid'. In choosing not to use apt, I am encountering
> significant internal pressure to justify this decision.

It is certainly not great to be doing something else. It was done like
that just to solve these problems.

>> Keep in mind that we can't take over the stock MongoDB configuration
>> for the machine as it is today, since otherwise we're blocking charms
>> from using the package for their own needs, which means that in theory
>> any knowledge inserted into the package upgrading procedure will not
>> affect the data that is manipulated by juju itself.
>
> isn't this only an issue if we choose to colocate units on the state
> machine(s). IMO this isn't an issue today, and we can tackle it once we get
> to the point of having colocation. I am hoping that by that time the REST
> API will be another part of the solution.

Right, it means that you can't deploy a charm with the state server,
and that a standard apt-get upgrade can affect the running database.

>> 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.
>
> Yes, this requirement has been highlighted throughout this discussion.

Sounds great, thank you.


gustavo @ http://niemeyer.net2