Open Stack

On 17/01/17 13:00, 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? 

Could we create a new tag (at
https://governance.openstack.org/tc/reference/tags/) to indicate the
project is trusted to be integrated. Then, if there is a existing
project want to use a feature in the trusted-integrated project, then no
new wheel. To be more clear, the integration is a force integration.
Look at this list, https://www.openstack.org/software/project-navigator/
most of the projects has been developed more than 3 years,
unfortunately, they're not trusted, on the contrary, sometimes we're
brave to use some 3rd party library very new. That's a little ironic.

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

-- 
Cheers & Best regards,
FeiLong Wang (王飞龙)
--------------------------------------------------------------------------
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--------------------------------------------------------------------------