[openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

Hayes, Graham graham.hayes at hpe.com
Fri Jul 15 15:52:48 UTC 2016


On 14/07/2016 21:33, Fox, Kevin M wrote:
> I'm going to go ahead and ask the difficult question now as the answer is relevant to the attached proposal...
>
> Should we reconsider whether the big tent is the right approach going forward?
>
> There have been some major downsides I think to the Big Tent approach, such as:
>  * Projects not working together because of fear of adding extra dependencies Ops don't already have
>  * Reimplementing features, badly, over and over again in different projects instead of standardizing something.
>  * More projects being created due to politics and not technical reasons.
>  * Less cross project communication
>  * Greater Operator pain at trying to assemble a more loose confederation of projects into something useful.
>  * General pushing off more and more work to Operators/Users to deal with.
>  * Worse User experience as cross project issues aren't being addressed.
>  * Previously incubated projects such as Nova, Swift, etc getting a disproportionate say in things as they have a greater current user base, and its increasingly hard now for new projects to gain any traction.
>  * Much less community pressure on projects to work together to elevate everyone. Architectural decisions are now made at individual project level with little done at the OpenStack level.
>  * etc...
>
> The overall goal of the Big Tent was to make the community more inclusive. That I think has mostly happened. Which is good. But It also seems to have fractured the community more into insular islands and made the system harder for our operators/users. Which is bad.
>
> Maybe the benefits outweigh the drawbacks. I'm not sure. But I think its probably time to consider if it has been a net positive and should be further refined to try and address some of these problems, or a net negative and different approaches be explored.
>
> Thanks,
> Kevin

Sure - having a review of a major governance change like the big-tent
is a good idea, and pretty good practice.

I personally don't think we have reached the end of the transition yet,
and proposals like mine will start to come along and deal with issues
outlined above. We should be sure that we have gone as far as we can
before we claim defeat.

That said, there is serious issues - with cross project fairness being
one of the big ones (from my perspective anyway). I think getting
concrete examples of problems and tackling them is a good road forward.

- Graham

> ________________________________________
> From: Hayes, Graham [graham.hayes at hpe.com]
> Sent: Thursday, July 14, 2016 12:21 PM
> To: OpenStack Development Mailing List (not for usage questions); openstack-tc at lists.openstack.org
> Subject: [openstack-dev] [tc][all] Plugins for all
>
> I just proposed a review to openstack/governance repo [0] that aims
> to have everything across OpenStack be plugin based for all cross
> project interaction, or allow all projects access to the same internal
> APIs and I wanted to give a bit of background on my motivation, and how
> it came about.
>
> Coming from a smaller project, I can see issues for new projects,
> smaller projects, and projects that may not be seen as "important".
>
> As a smaller project trying to fit into cross project initiatives,
> (and yes, make sure our software looks at least OK in the
> Project Navigator) the process can be difficult.
>
> A lot of projects / repositories have plugin interfaces, but also
> have project integrations in tree, that do not follow the plugin
> interface. This makes it difficult to see what a plugin can, and
> should do.
>
> When we moved to the big tent, we wanted as a community to move to
> a flatter model, removing the old integrated status.
>
> Unfortunately we still have areas when some projects are more equal -
> there is a lingering set of projects who were integrated at the point
> in time that we moved, and have preferential status.
>
> A lot of the effects are hard to see, and are not insurmountable, but
> do cause projects to re-invent the wheel.
>
> For example, quotas - there is no way for a project that is not nova,
> neutron, cinder to hook into the standard CLI, or UI for setting
> quotas. They can be done as either extra commands
> (openstack dns quota set --foo bar) or as custom panels, but not
> the way other quotas get set.
>
> Tempest plugins are another example. Approximately 30 of the 36
> current plugins are using resources that are not supposed to be
> used, and are an unstable interface. Projects in tree in tempest
> are at a much better position, as any change to the internal
> API will have to be fixed before the gate merges, but other
> out of tree plugins are in a place where they can be broken at any
> point.
>
> None of this is meant to single out projects, or teams. A lot
> of the projects that are in this situation have inordinate amounts of
> work placed on them by the big-tent, and I can emphasize with why things
> are this way. These were the examples that currently stick out
> in my mind, and I think we have come to a point where we need to make
> a change as a community.
>
> By moving to a "plugins for all" model, these issues are reduced.
> It undoubtedly will cause more, but it is closer to our goal
> of Recognizing all our community is part of OpenStack, and
> differentiate projects by tags.
>
> This won't be a change that happens tomorrow, next week, or even next
> cycle, but think as a goal, we should start moving in this direction
> as soon as we can, and start building momentum.
>
> Thanks,
>
> Graham
>
> 0 - https://review.openstack.org/342366
>
> __________________________________________________________________________
> 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
>




More information about the OpenStack-dev mailing list