I also feel like the drivers/plugins are currently BEYOND a tipping point, and are in fact dragging down velocity of the core project in many ways. I'm working on a proposal for Kilo where we move all drivers/plugins out of the main Neutron tree and into a separate git repository under the networking program. We have way too many drivers, requiring way too man review cycles, for this to be a sustainable model going forward. Since the main reason plugin/driver authors want their code upstream is to be a part of the simultaneous release, and thus be packaged by distributions, having a separate repository for these will satisfy this requirement. I'm still working through the details around reviews of this repository, etc.
Also, I feel as if the level of passion on the mailing list has died down a bit, so I thought I'd send something out to try and liven things up a bit. It's been somewhat non-emotional here for a day or so. :) Thanks, Kyle On Thu, Aug 14, 2014 at 5:09 AM, Salvatore Orlando <sorla...@nicira.com> wrote: > I think there will soon be a discussion regarding what the appropriate > location for plugin and drivers should be. > My personal feeling is that Neutron has simply reached the tipping point > where the high number of drivers and plugins is causing unnecessary load for > the core team and frustration for the community. > > There I would totally support Luke's initiative about maintaining an > out-of-tree ML2 driver. On the other hand, a plugin/driver "diaspora" might > also have negative consequences such as frequent breakages such as those Bob > was mentioning or confusion for users which might need to end up fetching > drivers from disparate sources. > > As mentioned during the last Neutron IRC meeting this is another "process" > aspect which will be discussed soon, with the aim of defining a plan for: > - drastically reduce the number of plugins and drivers which must be > maintained in the main source tree > - enhance control of plugin/driver maintainers over their own code > - preserve the ability of doing CI checks on gerrit as we do today > - raise the CI bar (maybe finally set the smoketest as a minimum > requirement?) > > Regards, > Salvatore > > > > On 14 August 2014 11:47, loy wolfe <loywo...@gmail.com> wrote: >> >> >> >> >> On Thu, Aug 14, 2014 at 4:22 PM, Mathieu Rohon <mathieu.ro...@gmail.com> >> wrote: >>> >>> Hi, >>> >>> I would like to add that it would be harder for the community to help >>> maintaining drivers. >>> such a work [1] wouldn't have occured with an out of tree ODL driver. >> >> >> +1. >> It's better to move all MD for none built-in backend out of tree, >> maintaining these drivers shouldn't be the responsibility of community. Not >> only MD, but also plugin, agent should all obey this rule >> >>> >>> >>> [1] https://review.openstack.org/#/c/96459/ >>> >>> On Wed, Aug 13, 2014 at 1:09 PM, Robert Kukura <kuk...@noironetworks.com> >>> wrote: >>> > One thing to keep in mind is that the ML2 driver API does sometimes >>> > change, >>> > requiring updates to drivers. Drivers that are in-tree get updated >>> > along >>> > with the driver API change. Drivers that are out-of-tree must be >>> > updated by >>> > the owner. >>> > >>> > -Bob >>> > >>> > >>> > On 8/13/14, 6:59 AM, ZZelle wrote: >>> > >>> > Hi, >>> > >>> > >>> > The important thing to understand is how to integrate with neutron >>> > through >>> > stevedore/entrypoints: >>> > >>> > >>> > https://github.com/dave-tucker/odl-neutron-drivers/blob/master/setup.cfg#L32-L34 >>> > >>> > >>> > Cedric >>> > >>> > >>> > On Wed, Aug 13, 2014 at 12:17 PM, Dave Tucker <d...@dtucker.co.uk> >>> > wrote: >>> >> >>> >> I've been working on this for OpenDaylight >>> >> https://github.com/dave-tucker/odl-neutron-drivers >>> >> >>> >> This seems to work for me (tested Devstack w/ML2) but YMMV. >>> >> >>> >> -- Dave >>> >> >>> >> _______________________________________________ >>> >> OpenStack-dev mailing list >>> >> OpenStack-dev@lists.openstack.org >>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > OpenStack-dev mailing list >>> > OpenStack-dev@lists.openstack.org >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> > >>> > >>> > _______________________________________________ >>> > OpenStack-dev mailing list >>> > OpenStack-dev@lists.openstack.org >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev