Open Stack

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