Open Stack

On Thu, Aug 14, 2014 at 9:07 PM, Kyle Mestery <mestery at mestery.com> wrote:

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

not "all" drivers/plugins, but "most" which are not built-in. For example,
ML2 with ovs/linux/sriov MD and l2pop MD should be kept in tree as the
default built-in backend, but all vendor specific MD and shim REST proxy
like all kinds of SDN controller MD should be removed out.


> 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
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140815/cb76553a/attachment.html>