Open Stack

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.

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

-Rob



-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud