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...
Yes, fair, good point, thanks for the correction.
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.
Great!
Thanks, we have to avoid becoming siloed off into
'openstack-world/universe'; I'm pretty sure it's the only way we survive.
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?
A good question, and one I've been pondering on for a while.
Honestly I'm not sure I could say what would be 'left', especially as
there is overlap in functionality, but let's say we are proactive in say
shifting things (in places where we are actually more advanced or
provide unique value that the CNCF and its projects lack) then what did
not shift over is what is left in openstack (as it is defined today).
But what is wrong with that, if openstack becomes openstack-CNCF, so
what, it feels somewhat evolutionary and I get the gut feeling it's
happening whether we want it to or not (though of course I only have a
small view on the wider world).
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.
Perhaps that's an opportunity, not a drawback? If we play the cards
right and approach this correctly we can help evolve (our community and
theres) into something that transfers what we have learned from our
current community to whatever it becomes next.
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?
Ya, I'm not really happy either with this, but I've seen it before.
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.
I guess I call what you are feeling above as modernizing.
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.
Do we have to settle for that, let's imagine a better world and try to
unify these two groups/foundations together. Why settle for 'the way it
is' or we'll just go our separate and duplicate ways until entropy
shifts to it's next destination (by people and project and talent
attrition....); why can't we do better than this instead? We are all
working in cloud (and/or related areas), why do we have to treat our
communities as two separate universes :-/
-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
