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

Fox, Kevin M Kevin.Fox at pnnl.gov
Tue Jan 17 00:00:37 UTC 2017


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?

Thanks,
Kevin
________________________________________
From: Jay Pipes [jaypipes at gmail.com]
Sent: Monday, January 16, 2017 1:57 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

On 01/16/2017 04:09 PM, Fox, Kevin M wrote:
> If the developers that had issue with the lack of functionality,
> contributed to Barbican rather then go off on their own, the problem
>  would have been solved much more quickly. The lack of sharing means
>  the problems don't get fixed as fast.

Agreed completely.

> As for operators, If the more common projects all started depending
> on it, it would be commonly deployed.

Also agreed.

> Would the operators deploy Barbican just for Magnum? maybe not. maybe
> so. For Magnum, Ironic, and Sahara, more likely . Would they deploy
> it if Neutron and Keystone depended on it, yeah. they would. And then
> all the other projects would benefit from it being there, such as
> Magnum.

Totally agreed.

 > The sooner OpenStack as a whole can decide on some new core
> components so that projects can start hard depending on them, the
> better I think. That process kind of stopped with the arrival of the
> big tent.

You are using a false equivalence again.

As I've mentioned numerous times before on the mailing list, the Big
Tent was NOT either of these things:

* Expanding what the "core components" of OpenStack
* Expanding the mission or scope of OpenStack

What the Big Tent -- technically "Project Structure Reform" -- was about
was actually the following:

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

What you are complaining about (rightly IMHO) regarding OpenStack
project contributors not contributing missing functionality to Barbican
has absolutely nothing to do with the Big Tent:

There's no competing secret storage project in OpenStack other than
Barbican/Castellan.

Furthermore, this behaviour of projects choosing to DIY/NIH something
that existed in other projects was around long before the advent of the
Big Tent. In fact, in this specific case, the Magnum team knew about
Barbican, previously depended on it, and chose to make Barbican an
option not because Barbican wasn't OpenStack -- it absolutely WAS -- but
because it wasn't commonly deployed, which limited their own adoption.

What you are asking for, Kevin, is a single opinionated and consolidated
OpenStack deployment; a single OpenStack "product" if you will. This is
a perfectly valid request. However it has nothing to do with the Big
Tent governance reform.

Best,
-jay

__________________________________________________________________________
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