Interim plan to move away from the mongo tarball

[David Cheney]

> One of the reasons for the out-of-band tarball was that it gave us an
> easy way to have the same MongoDB version running on all past
> releases, and to have fine-grained control of exactly when and how to
> upgrade it.

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.

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

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

Cheers

Dave