On 14/07/2016 21:20, Matt Riedemann wrote: > On 7/14/2016 2: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. >> >> 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-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > Just for my own understanding, are you suggesting that something like > nova, cinder or neutron become optional for an openstack cloud?
Not in this proposal. (but that is an interesting idea we should follow up on at a later date) > And does this also include plugins within projects, like storage > backends in cinder and hypervisor drivers in nova? This is aimed at cross project interaction. So, if there is a project in projects.yaml that is a backend, or a hypervisor driver, it should. However, in the proposal, there is a choice that projects can make - all in tree, or all plugins. The point of the proposal is equality of access for the community. What would that mean in practice for Nova? Nothing would really change - they have decided to do in tree. 99% of deliverables tagged type:service will have no impact from this, the change will be in projects that are used by teams across the community (CLI, Docs, UI etc), and provide a way for these projects to integrate with them. These integration points should be the same for *all* projects. > Nova has been pushing for a few releases now on getting rid of plug > points since they are barriers to interoperability. Well, nova's plugins were barriers to interoperability, for other projects they are the only mechanism for interoperability. __________________________________________________________________________ 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