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