Open Stack

Robert Collins wrote:
> On 19 September 2014 22:29, Thierry Carrez <thierry at openstack.org> wrote:
> ...
>> current Heat team is not really interested in maintaining them. What's
>> the point of being under the same program then ? And TripleO is not the
>> only way to deploy OpenStack, but its mere existence (and name)
>> prevented other flowers to bloom in our community.
> 
> So I've a small issue here - *after* TripleO became an official
> program Tuskar was started - and we embraced and shuffled things to
> collaborate. There's a tripleo puppet repository, an ansible one
> coming soon I believe, and I'm hearing rumours of a spike using
> another thing altogether (whose thunder I don't want to steal so I'm
> going to be vague :)). We've collaborated to a degree with Fuel and
> Crowbar: I am not at all sure we've prevented other flowers blooming -
> and I hate the idea that we have done that.

I agree that you went out of your way to be inclusive, but having a
single PTL for a group of competing alternatives is a bit weird. As far
as "preventing blooming", that's something we've heard from the Board of
Directors (as part of an objection to calling the TripleO program
"OpenStack Deployment").

> ...
>> ## The release and the development cycle
>>
>> You touch briefly on the consequences of your model for the "common
>> release" and our development cycle. Obviously we would release the ring
>> 0 projects in an integrated manner on a time-based schedule.
> 
> I'm not at all sure we need to do that - I've long been suspicious of
> the coordinated release. I see benefits to users in being able to grab
> a new set of projects all at once, but they can do that irrespective
> of our release process, as long as:
> 
> *) we do releases
> *) we do at least one per project per 6 month period
> 
> Tying all our things together makes for hugely destablising waves of
> changes and rushes: if we aimed at really smooth velocity and frequent
> independent releases I think we could do a lot better: contracts and
> interfaces are *useful* things for large scale architectures, and we
> need to stop kidding ourselves - OpenStack is not a lean little
> beastie anymore: its a large scale distributed system. Swift is doing
> exactly the right thing today - I'd like to see more of that.

Note that I'm only advocating that Monty's layer #1 things would be
released in an integrated manner on a time-based schedule. That's not
"all our things". All the other things would be released as-needed. That
lets us focus on cleaning up interfaces between layer #1 and other
things first. Swift is doing the right thing today because its
loosely-integrated with layer #1 (and has a clean interface for doing
so). So Swift is doing the right thing for an non-layer#1 project.

Once our layer#1-internal interfaces are simple/stable enough that we
can safely compose something that works at any time by picking the
latest version of everything, we can discuss the benefits and the
drawbacks of the "common release" model. I still think there are huge
community benefits to sharing the same cycle, and gathering around a
common "release" that can be advertised and consumed downstream... as
far as layer #1 is concerned.

-- 
Thierry Carrez (ttx)