[openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

Jay Pipes jaypipes at gmail.com
Tue Jan 17 19:25:42 UTC 2017


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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list