Interim plan to move away from the mongo tarball

[Mark Ramm]

On Wed 27 Mar 2013 03:29:28 PM EST, Gustavo Niemeyer wrote:
> A solution has been mentioned in this thread that is both simple and
> works, and is apparently being ignored in your coverage.
>
> It's worrisome that every conversation is quickly being thrown under
> the "we don't have time" bandwagon lately. If you're in such a hurry,
> you can do nothing rather than half-baking a solution that has seen
> little discussion and has known real problems being ignored. What
> exists today isn't perfect but works, and if you can't spare the time
> to build a tarball with binaries, nothing else will do.
>
>
>> If necessary we can add a PPA at cloud init time to address this issue, or fall back to putting things in a public bucket -- but the mantanance of the public bucket tools  across clouds and OS releases is already a problem that we don't have time to solve properly. (See all the threads about HP Tools in the main juju list) by 13.04, so I am hesitant to suggest that reverting to that would make things easier in the short term.   And nothing we are doing now commits us to a long term position on this issue, so for the sake of making the release, I think we have to go forward as Dave has described.
>>
>> But if we are asking theoretical questions, do we expect that the Mongo 2.4 tarball will work equally on all past and future Ubuntu versions? What would we do if we needed to apply a OS version specific bugfix or security release?
>>
>> Other questions which have been raised are: What's the Juju policy on security issues in Mongo, how is that coordinated with the security team?
>>
>> IMHO, There are almost certainly good answers to these questions, but given that we have a known working solution that gets this moving forward, and allows for us to easily change in the future, I am hesitant to get tied up in long discussions on these issues at the moment.
>>
>> --Mark Ramm

I don't believe the solution you describe is being ignored.

There has  been significant discussion around the tarball solution and 
a non trivial amount of effort to make it work.

But in the end the team made a decision to re-use existing tools in the 
package management space -- at least for now.

To do the tarball solution correctly requires addressing signing the 
tarballs, managing transport security properly on a variety of clouds, 
handling clouds without object storage, managing potential 
incompatibility across OS releases, etc.

Just to be clear, I am not the author of the current strategy I'm just 
summarizing the case made for that strategy by various folks on the 
team.  After many discussions (where your suggestion was given lots of 
weight) the team made some decisions and Dave has done his best to turn 
that into a proposal on the list, and then into action.

My only role in this whole thing up to this point was to 1) try to make 
sure the discussions happened in Atlanta, and 2) to help keep this 
thread moving forward by summarizing my best understanding of the 
conclusions that came out of those discussions and to help bring you up 
to speed on the contents of those meetings.

With that said, I am interested to hear your thoughts about the various 
issues raised with respect to security and OS compatibility.  I'm also 
interested in your response to the potential solution to the "not 
available everywhere" problem of adding a PPA we control to the list of 
package archives at cloud-init time. I know we are all interested in 
creating the best most supportable version of juju possible, and I want 
to make sure that we are getting the best information possible, so that 
we can make the best possible decisions.

--Mark Ramm

P.S.  The ease of reversibility of a decision does play pretty deeply 
into my thinking on how much time it is worth arguing over the details. 
  And I think it's pretty easy to go back to tarballs if we decide that 
is the way to go, which is the point I was trying to make in the 
previous e-mail.

All of which is just to say I don't consider this to be the type of 
"bet the farm" decisions that require significant investments of time 
to get right before we can move forward. But that does not mean that we 
should ignore it, or not try to get it right, it just means that we 
have other even more significant priorities at the moment.   I think 
prioritization is critical to being able to ship a working product, and 
we are trying to do the best we can here.   If you disagree with the 
priority list, that's also worthy of a discussion because prioritizing 
everything correctly is a very hard job, and I doubt we have done a 
perfect job of it.