On 01/16/2017 07:19 PM, Joshua Harlow wrote:
Fox, Kevin M wrote:
Your right, it is not what the big tent was about, but the big tent
had some unintended side affects. The list, as you stated:
* No longer having a formal incubation and graduation period/review for
applying projects
* Having a single, objective list of requirements and responsibilities
for inclusion into the OpenStack development community
* Specifically allowing competition of different source projects in the
same "space" (e.g. deployment or metrics)
Turned into (my opinion):
#1, projects, having a formal incubation/graduation period had the
opportunity to get feedback on what they could do to better integrate
with other projects and were strongly encouraged to do so to make
progress towards graduation. Without the formality, no one tended to
bother.
#2, Not having a single, objective list of
requirements/responsibility: I believe not having a list made folks
take a hard look at what other projects were doing and try harder to
play nice in order to get graduated or risk the unknown of folks
coming back over and over and telling them more integration was required.
#3, the benefits/drawbacks of specifically allowing competition is
rather hard to predict. It can encourage alternate solutions to be
created and create a place where better ideas can overcome less good
ideas. But it also removes pressure to cooperate on one project rather
then just take the sometimes much easier route of just doing it
yourself in your own project.
I'm not blaming the big tent for all the ills of the OpenStack world.
It has had some real benefits. This problem is something bigger then
the big tent. It preexisted the tent. The direction the pressure to
share was very unidirectional pre big tent, applied to new projects
much more then old projects.
But, I'm just saying the Big Tent had an (unintended) net negative
affect making this particular problem worse.
Looking at the why of a problem is one of the important steps to
formulating a solution. OpenStack no longer has the amount of tooling
to help elevate the issue it had under the time before the Big Tent.
Nothing has come up since to replace it.
I'm not stating that the big tent should be abolished and we go back
to the way things were. But I also know the status quo is not working
either. How do we fix this? Anyone have any thoughts?
Embrace the larger world instead of trying to recreate parts of it,
create alliances with the CNCF and/or other companies
The CNCF isn't a company...
that are getting actively involved there and make bets that solutions
there are things that people want to use directly (instead of turning
openstack into some kind of 'integration aka, middleware engine').
The complaint about Barbican that I heard from most folks on this thread
was that it added yet another service to deploy to an OpenStack deployment.
If we use technology from the CNCF or elsewhere, we're still going to
end up deploying yet another service. Just like if we want to use
ZooKeeper for group membership instead of the Nova DB.
So, while I applaud the general idea of looking at the CNCF projects as
solutions to some problems, you wouldn't be solving the actual issue
brought to attention by operators and OpenStack project contributors (to
Magnum/Craton): of needing to install yet another dependency.
How many folks have been watching
https://github.com/cncf/toc/tree/master/proposals or
https://github.com/cncf/toc/pulls?
I don't look at that feed, but I do monitor the pull requests for k8s
and some other projects like rkt and ACI/OCI specs.
Start accepting that what we call OpenStack may be better off as
extracting the *current* good parts of OpenStack and cutting off some of
the parts that aren't really worth it/nobody really uses/deploys anyway
I'm curious what you think would be left in OpenStack?
BTW, the CNCF is already creating projects that duplicate functionality
that's been available for years in other open source projects -- see
prometheus and fluentd [1] -- in the guise of "unifying" things for a
cloud-native world. I suspect that trend will continue as vendors jump
from OpenStack to CNCF projects because they perceive it as the new
shiny thing and capable of accepting their vendor-specific code quicker
than OpenStack.
In fact, if you look at the CNCF projects, you see the exact same
disagreement about the exact same two areas that we see so much
duplication in the OpenStack community: deployment/installation and
logging/monitoring/metrics. I mean, how many ways are there to deploy
k8s at this point?
The things that the OpenStack ecosystem has proliferated as services or
plugins are the exact same things that the CNCF projects are building
into their architecture. How many service discovery mechanisms can
Prometheus use? How many source and destination backends can fluentd
support? And now with certain vendors trying to get more
hardware-specific functionality added to k8s [2], the k8s community is
going through the exact same inflection point with regards to project
scope that Nova did 4 years ago.
What's old is new and what's new is old again.
> (and say starting to modernize the parts that are left by say moving
> them under the CNCF umbrella and adopting some of the technology there
> instead).
I find it curious that you equate "modernizing" an OpenStack project to
"moving it to the CNCF umbrella". Is the technology you would want to
adopt just simply Golang vs. Python or are you referring to something
else? Perhaps k8s' choice not to use a relational database for any state
storage?
Look, I'm not saying the CNCF projects are bad in any way. I have
*daily* feelings of jealousy when looking at some of the k8s and fluentd
architecture/code and wonder what would Nova look like if we'd started
coding it now from scratch. Almost weekly I wish that Nova would have
the freedom that k8s currently has to change direction mid-stream. But
k8s is also in a different maturity/lifecycle place than Nova is and has
a very different and smaller mission.
My point is this: I don't want people to think that the structure and
governance of the OpenStack project ecosystem is the reason that there
have been certain duplicative efforts made in partiocular areas. That
duplication of effort is going to continue in both OpenStack and the
CNCF ecosystems because deployment/packaging/installation and
monitoring/metrics are the two primary areas where nobody will ever
agree there is a One True Way. [3]
It's just the way it is. At least, that's my two cents.
Best,
-jay
[1] and don't get me started on the open core stuff.
[2] https://github.com/kubernetes/community/pull/171
[3] Incidentally, this is the same reason why there was a proliferation
of config management systems like Chef, Puppet, cfengine, SaltStack,
Ansible, etc. Operators/deployers will NEVER be able to agree on a
single best mechanism for deploying and configuring their snowflakes.
Rinse and repeat this same shift after say another ~6 years when the
CNCF accumulates enough projects that nobody really uses/deploys.
-Josh
__________________________________________________________________________
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
__________________________________________________________________________
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
