Open Stack

Excerpts from Thomas Goirand's message of 2016-04-19 05:59:19 -0700:
> On 04/19/2016 01:01 PM, Chris Dent wrote:
> > We also, however, need to consider what the future might look like and
> > at least for some people and situations
> 
> I agree.
> 
> > the future does not involve
> > debs or rpms of OpenStack: packages and distributions are more trouble
> > than they are worth when you want to be managing your infrastructure
> > across multiple, isolated environments.
> 
> But here, I don't. It is my view that best, for containers, is to build
> them using distribution packages.
> 
> > In that case you want
> > puppet, ansible, chef, docker, k8s, etc.
> > 
> > Sure all those things _can_ use packages to do their install but for
> > at least _some_ people that's redundant: deploy from a tag, branch,
> > commit or head of a repo.
> > 
> > That's for _some_ people.
> 
> This thinking (ie: using pip and trunk, always) was one of the reason
> for TripleO to fail, and they went back to use packages. Can we learn
> from the past?
> 

I want to clarify something here because what you say above implies that
the reason a whole lot of us stopped contributing to TripleO was that we
"failed", or that the approach was wrong.

There was never an intention to preclude packages entirely. Those of
us initially building TripleO did so with continuous delivery as the
sole purpose that _we_ had. RedHat's contributors joined in and had a
stable release focus, and eventually as our sponsors changed their mind
about what they wanted from TripleO, we stopped pushing the CD model,
because we weren't even working on the project anymore. This left a void,
and RedHat's stable release model was obviously better served by using
the packaging tools they are already familiar with, thus the project now
looks like it pivoted. But it's really more that one set of contributors
stopped working on one use case, and another set ramped up contribution
on a different one.

So please, do not use the comment above to color this discussion.
Continuous delivery is a model that people will use to great success,
and in that model, dependency management is _very_ different.