[openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

Thierry Carrez thierry at openstack.org
Fri Jun 23 09:31:50 UTC 2017


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

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.

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] https://ttx.re/facets-of-the-integrated-release.html

-- 
Thierry Carrez (ttx)



More information about the OpenStack-dev mailing list