Open Stack

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 <sorlando at 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 <loywolfe at gmail.com> wrote:
>>
>>
>>
>>
>> On Thu, Aug 14, 2014 at 4:22 PM, Mathieu Rohon <mathieu.rohon at 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 <kukura at 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 <dave at 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 at lists.openstack.org
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev at lists.openstack.org
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev at lists.openstack.org
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>