[openstack-dev] [tc][all] Plugins for all

Andrew Laski andrew at lascii.com
Fri Jul 15 16:04:49 UTC 2016



On Thu, Jul 14, 2016, at 03:21 PM, Hayes, Graham wrote:
> 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.

Which internal APIs are you referring to here? Are you limiting this to
internal APIs within Tempest/Devstack that projects can use for
testing/deployment, or are you referring to things like the nova-compute
service which has an internal RPC API?

I feel like I'm missing some context when reading this email because
there are a lot of references to plugins with no clear definition, that
I can see, of what exactly you mean by that.

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

Can you provide more clarity on how "openstack dns quota set --foo bar"
differs from setting a quota on Nova/Neutron/Cinder?

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

Has there been an attempt to elevate these internal interfaces into
stable and publicly consumable interfaces? Was there resistance to such
an effort?

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

Is this just a matter of nobody is doing this work, or are there claims
that some projects are special and should have access that other
projects do not?

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



More information about the OpenStack-dev mailing list