Open Stack

On 23/06/17 05:31, Thierry Carrez wrote:
> Zane Bitter wrote:
>> But back in the day we had a process (incubation) for adding stuff to
>> OpenStack that it made sense to depend on being there. It was a highly
>> imperfect process. We got rid of that process with the big tent reform,
>> but didn't really replace it with anything at all. Tags never evolved
>> into a replacement as I hoped they would.
>>
>> So now we have a bunch of things that are integral to building a
>> "Kubernetes-like experience for application developers" - secret
>> storage, DNS, load balancing, asynchronous messaging - that exist but
>> are not in most clouds.
> 
> Yet another tangent in that thread, but you seem to regret a past that
> never happened.

It kind of did. The TC used to require that new projects graduating into 
OpenStack didn't reimplement anything that an existing project in the 
integrated release already did. e.g. Sahara and Trove were required to 
use Heat for orchestration rather than rolling their own orchestration. 
The very strong implication was that once something was officially 
included in OpenStack you didn't develop the same thing again. It's true 
that nothing was ever enforced against existing projects (the only 
review was at incubation/graduation), but then again I can't think of a 
situation where it would have come up at that time.

> The "integrated release" was never about stuff that you
> can "depend on being there". It was about things that were tested to
> work well together, and released together. Projects were incubating
> until they were deemed mature-enough (and embedded-enough in our
> community) that it was fine for other projects to take the hit to be
> tested with them, and take the risk of being released together. I don't
> blame you for thinking otherwise: since the integrated release was the
> only answer we gave, everyone assumed it answered their specific
> question[1]. And that was why we needed to get rid of it.

I agree and I supported getting rid of it. But not all of the roles it 
fulfilled (intended or otherwise) were replaced with anything. One of 
the things that fell by the wayside was the sense some of us had that we 
were building an integrated product with flexible deployment options, 
rather than a series of disconnected islands.

> If it was really about stuff you can "depend on being there" then most
> OpenStack clouds would have had Swift, Ceilometer, Trove and Sahara.
> 
> Stuff you can "depend on being there" is a relatively-new concept:
> https://governance.openstack.org/tc/reference/base-services.html
> 
> Yes, we can (and should) add more of those when they are relevant to
> most OpenStack deployments, otherwise projects will never start
> depending on Barbican and continue to NIH secrets management locally.
> But since any addition comes with a high operational cost, we need to
> consider them very carefully.

+1

> We should also consider use cases and group projects together (a concept
>   we start to call "constellations"). Yes, it would be great that, if you
> have a IaaS/Compute use case, you could assume Designate is part of the mix.

+1

> [1] https://ttx.re/facets-of-the-integrated-release.html
>