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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
