Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[Kevin Benton]

It's more than just an optimization when it comes to overlay networks
though. It's the only way for agents to establish segment connectivity when
something like vxlan multicast discovery isn't possible. It shouldn't be
l2pop's responsibility for something like basic connectivity. That should
be handled by the tunnel type drivers.

I'm fine with l2pop optimizing things like ARP responses and tunnel
pruning, but a network should still be able to function without l2pop.


On Wed, Aug 27, 2014 at 6:36 AM, Mathieu Rohon 
wrote:

> l2pop is about l2 networks optimization with tunnel creation and arp
> repsonder population (so this is
> not only a overlays network optimization. For example ofagent now use
> l2pop info for flat and vlan optimization [1]),
> This optimization is orthogonal to several agent based mechanism
> driver (lb, ovs, ofagent).
> I agree that this optimization should be accessible to every MD, by
> providing an access to fdb dict directly from ML2.db.
> a controler based MD like ODL could use those fdb entries the same way
> agents use it, by optimizing the datapath under its control.
>
> [1]https://review.openstack.org/#/c/114119/
>
> On Wed, Aug 27, 2014 at 10:30 AM, Kevin Benton  wrote:
> >>So why not agent based?
> >
> > Maybe I have an experimental operating system that can't run python.
> Maybe
> > the RPC channel between compute nodes and Neutron doesn't satisfy certain
> > security criteria. Regardless of the reason, it doesn't matter because
> that
> > is an implementation detail that should be irrelevant to separate ML2
> > drivers.
> >
> > l2pop should be concerned with tunnel endpoints and tunnel endpoints
> only.
> > Whether or not you're running a chunk of code responding to messages on
> an
> > RPC bus and sending heartbeats should not be Neutron's concern. It
> defeats
> > the purpose of ML2 if everything that can bind a port has to be running a
> > neutron RPC-compatible agent.
> >
> > The l2pop functionality should become part of the tunnel type drivers and
> > the mechanism drivers should be able to provide the termination endpoints
> > for the tunnels using whatever mechanism it chooses. Agent-based drivers
> can
> > use the agent DB to do this and then the REST drivers can provide
> whatever
> > termination point they want. This solves the interoperability problem and
> > relaxes this tight coupling between vxlan and agents.
> >
> >
> > On Wed, Aug 27, 2014 at 1:09 AM, loy wolfe  wrote:
> >>
> >>
> >>
> >>
> >> On Wed, Aug 27, 2014 at 3:13 PM, Kevin Benton 
> wrote:
> >>>
> >>> Ports are bound in order of configured drivers so as long as the
> >>> OpenVswitch driver is put first in the list, it will bind the ports it
> can
> >>> and then ODL would bind the leftovers. [1][2] The only missing
> component is
> >>> that ODL doesn't look like it uses l2pop so establishing tunnels
> between the
> >>> OVS agents and the ODL-managed vswitches would be an issue that would
> have
> >>> to be handled via another process.
> >>>
> >>> Regardless, my original point is that the driver keeps the neutron
> >>> semantics and DB in tact. In my opinion, the lack of compatibility with
> >>> l2pop isn't an issue with the driver, but more of an issue with how
> l2pop
> >>> was designed. It's very tightly coupled to having agents managed by
> Neutron
> >>> via RPC, which shouldn't be necessary when it's primary purpose is to
> >>> establish endpoints for overlay tunnels.
> >>
> >>
> >> So why not agent based? Neutron shouldn't be treated as just an resource
> >> storage, built-in backends naturally need things like l2pop and dvr for
> >> distributed dynamic topology control,  we couldn't say that something
> as a
> >> part was "tightly coupled".
> >>
> >> On the contrary, 3rd backends should adapt themselves to be integrated
> >> into Neutron as thin as they can, focusing on the backend device
> control but
> >> not re-implement core service logic duplicated with Neutron . BTW,
> Ofagent
> >> is a good example for this style.
> >>
> >>>
> >>>
> >>>
> >>> 1.
> >>>
> https://github.com/openstack/neutron/blob/7f466c8730cfca13f2fb374c80d810929bb8/neutron/plugins/ml2/drivers/mech_agent.py#L53
> >>> 2.
> >>>
> https://github.com/openstack/neutron/blob/7f466c8730cfca13f2fb374c80d810929bb8/neutron/plugins/ml2/drivers/mechanism_odl.py#L326
> >>>
> >>>
> >>> On Tue, Aug 26, 2014 at 10:05 PM, loy wolfe 
> wrote:
> 
> 
> 
> 
>  On Wed, Aug 27, 2014 at 12:42 PM, Kevin Benton 
>  wrote:
> >
> > >I think that "opensource" is not the only factor, it's about
> built-in
> > > vs. 3rd backend. Built-in must be opensource, but opensource is not
> > > necessarily built-in. By my thought, current OVS and linuxbridge
> are
> > > built-in, but shim RESTful proxy for all kinds of sdn controller
> should be
> > > 3rd, for they keep all virtual networking data model and service
> logic in
> > > their own places, using Neutron API just as the NB shell (they
> can'

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[Mathieu Rohon]

l2pop is about l2 networks optimization with tunnel creation and arp
repsonder population (so this is
not only a overlays network optimization. For example ofagent now use
l2pop info for flat and vlan optimization [1]),
This optimization is orthogonal to several agent based mechanism
driver (lb, ovs, ofagent).
I agree that this optimization should be accessible to every MD, by
providing an access to fdb dict directly from ML2.db.
a controler based MD like ODL could use those fdb entries the same way
agents use it, by optimizing the datapath under its control.

[1]https://review.openstack.org/#/c/114119/

On Wed, Aug 27, 2014 at 10:30 AM, Kevin Benton  wrote:
>>So why not agent based?
>
> Maybe I have an experimental operating system that can't run python. Maybe
> the RPC channel between compute nodes and Neutron doesn't satisfy certain
> security criteria. Regardless of the reason, it doesn't matter because that
> is an implementation detail that should be irrelevant to separate ML2
> drivers.
>
> l2pop should be concerned with tunnel endpoints and tunnel endpoints only.
> Whether or not you're running a chunk of code responding to messages on an
> RPC bus and sending heartbeats should not be Neutron's concern. It defeats
> the purpose of ML2 if everything that can bind a port has to be running a
> neutron RPC-compatible agent.
>
> The l2pop functionality should become part of the tunnel type drivers and
> the mechanism drivers should be able to provide the termination endpoints
> for the tunnels using whatever mechanism it chooses. Agent-based drivers can
> use the agent DB to do this and then the REST drivers can provide whatever
> termination point they want. This solves the interoperability problem and
> relaxes this tight coupling between vxlan and agents.
>
>
> On Wed, Aug 27, 2014 at 1:09 AM, loy wolfe  wrote:
>>
>>
>>
>>
>> On Wed, Aug 27, 2014 at 3:13 PM, Kevin Benton  wrote:
>>>
>>> Ports are bound in order of configured drivers so as long as the
>>> OpenVswitch driver is put first in the list, it will bind the ports it can
>>> and then ODL would bind the leftovers. [1][2] The only missing component is
>>> that ODL doesn't look like it uses l2pop so establishing tunnels between the
>>> OVS agents and the ODL-managed vswitches would be an issue that would have
>>> to be handled via another process.
>>>
>>> Regardless, my original point is that the driver keeps the neutron
>>> semantics and DB in tact. In my opinion, the lack of compatibility with
>>> l2pop isn't an issue with the driver, but more of an issue with how l2pop
>>> was designed. It's very tightly coupled to having agents managed by Neutron
>>> via RPC, which shouldn't be necessary when it's primary purpose is to
>>> establish endpoints for overlay tunnels.
>>
>>
>> So why not agent based? Neutron shouldn't be treated as just an resource
>> storage, built-in backends naturally need things like l2pop and dvr for
>> distributed dynamic topology control,  we couldn't say that something as a
>> part was "tightly coupled".
>>
>> On the contrary, 3rd backends should adapt themselves to be integrated
>> into Neutron as thin as they can, focusing on the backend device control but
>> not re-implement core service logic duplicated with Neutron . BTW, Ofagent
>> is a good example for this style.
>>
>>>
>>>
>>>
>>> 1.
>>> https://github.com/openstack/neutron/blob/7f466c8730cfca13f2fb374c80d810929bb8/neutron/plugins/ml2/drivers/mech_agent.py#L53
>>> 2.
>>> https://github.com/openstack/neutron/blob/7f466c8730cfca13f2fb374c80d810929bb8/neutron/plugins/ml2/drivers/mechanism_odl.py#L326
>>>
>>>
>>> On Tue, Aug 26, 2014 at 10:05 PM, loy wolfe  wrote:




 On Wed, Aug 27, 2014 at 12:42 PM, Kevin Benton 
 wrote:
>
> >I think that "opensource" is not the only factor, it's about built-in
> > vs. 3rd backend. Built-in must be opensource, but opensource is not
> > necessarily built-in. By my thought, current OVS and linuxbridge are
> > built-in, but shim RESTful proxy for all kinds of sdn controller should 
> > be
> > 3rd, for they keep all virtual networking data model and service logic 
> > in
> > their own places, using Neutron API just as the NB shell (they can't 
> > even
> > co-work with built-in l2pop driver for vxlan/gre network type today).
>
>
> I understand the point you are trying to make, but this blanket
> statement about the data model of drivers/plugins with REST backends is
> wrong. Look at the ODL mechanism driver for a counter-example.[1] The data
> is still stored in Neutron and all of the semantics of the API are
> maintained. The l2pop driver is to deal with decentralized overlays, so 
> I'm
> not sure how its interoperability with the ODL driver is relevant.


 If we create a vxlan network,  then can we bind some ports to built-in
 ovs driver, and other ports to ODL driver? linux bridge agnet, ovs agent,
 of

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[Kevin Benton]

>So why not agent based?

Maybe I have an experimental operating system that can't run python. Maybe
the RPC channel between compute nodes and Neutron doesn't satisfy certain
security criteria. Regardless of the reason, it doesn't matter because that
is an implementation detail that should be irrelevant to separate ML2
drivers.

l2pop should be concerned with tunnel endpoints and tunnel endpoints only.
Whether or not you're running a chunk of code responding to messages on an
RPC bus and sending heartbeats should not be Neutron's concern. It defeats
the purpose of ML2 if everything that can bind a port has to be running a
neutron RPC-compatible agent.

The l2pop functionality should become part of the tunnel type drivers and
the mechanism drivers should be able to provide the termination endpoints
for the tunnels using whatever mechanism it chooses. Agent-based drivers
can use the agent DB to do this and then the REST drivers can provide
whatever termination point they want. This solves the interoperability
problem and relaxes this tight coupling between vxlan and agents.


On Wed, Aug 27, 2014 at 1:09 AM, loy wolfe  wrote:

>
>
>
> On Wed, Aug 27, 2014 at 3:13 PM, Kevin Benton  wrote:
>
>> Ports are bound in order of configured drivers so as long as the
>> OpenVswitch driver is put first in the list, it will bind the ports it can
>> and then ODL would bind the leftovers. [1][2] The only missing component is
>> that ODL doesn't look like it uses l2pop so establishing tunnels between
>> the OVS agents and the ODL-managed vswitches would be an issue that would
>> have to be handled via another process.
>>
>> Regardless, my original point is that the driver keeps the neutron
>> semantics and DB in tact. In my opinion, the lack of compatibility with
>> l2pop isn't an issue with the driver, but more of an issue with how l2pop
>> was designed. It's very tightly coupled to having agents managed by Neutron
>> via RPC, which shouldn't be necessary when it's primary purpose is to
>> establish endpoints for overlay tunnels.
>>
>
> So why not agent based? Neutron shouldn't be treated as just an resource
> storage, built-in backends naturally need things like l2pop and dvr for
> distributed dynamic topology control,  we couldn't say that something as a
> part was "tightly coupled".
>
> On the contrary, 3rd backends should adapt themselves to be integrated
> into Neutron as thin as they can, focusing on the backend device control
> but not re-implement core service logic duplicated with Neutron . BTW,
> Ofagent is a good example for this style.
>
>
>>
>>
>> 1.
>> https://github.com/openstack/neutron/blob/7f466c8730cfca13f2fb374c80d810929bb8/neutron/plugins/ml2/drivers/mech_agent.py#L53
>> 2.
>> https://github.com/openstack/neutron/blob/7f466c8730cfca13f2fb374c80d810929bb8/neutron/plugins/ml2/drivers/mechanism_odl.py#L326
>>
>>
>> On Tue, Aug 26, 2014 at 10:05 PM, loy wolfe  wrote:
>>
>>>
>>>
>>>
>>> On Wed, Aug 27, 2014 at 12:42 PM, Kevin Benton 
>>> wrote:
>>>
 >I think that "opensource" is not the only factor, it's about built-in
 vs. 3rd backend. Built-in must be opensource, but opensource is not
 necessarily built-in. By my thought, current OVS and linuxbridge are
 built-in, but shim RESTful proxy for all kinds of sdn controller should be
 3rd, for they keep all virtual networking data model and service logic in
 their own places, using Neutron API just as the NB shell (they can't even
 co-work with built-in l2pop driver for vxlan/gre network type today).


 I understand the point you are trying to make, but this blanket
 statement about the data model of drivers/plugins with REST backends is
 wrong. Look at the ODL mechanism driver for a counter-example.[1] The data
 is still stored in Neutron and all of the semantics of the API are
 maintained. The l2pop driver is to deal with decentralized overlays, so I'm
 not sure how its interoperability with the ODL driver is relevant.

>>>
>>> If we create a vxlan network,  then can we bind some ports to built-in
>>> ovs driver, and other ports to ODL driver? linux bridge agnet, ovs agent,
>>> ofagent can co-exist in the same vxlan network, under the common l2pop
>>> mechanism. By that scenery, I'm not sure whether ODL can just add to them
>>> in a heterogeneous multi-backend architecture , or work exclusively and
>>> have to take over all the functionality.
>>>
>>>

 1.
 https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mechanism_odl.py



 On Tue, Aug 26, 2014 at 7:14 PM, loy wolfe  wrote:

> Forwarded from other thread discussing about incubator:
>
> http://lists.openstack.org/pipermail/openstack-dev/2014-August/044135.html
>
>
>
>> Completely agree with this sentiment. Is there a crisp distinction
>> between a "vendor" plugin and an "open source" plugin though?
>>
>>
> I think that "opensource" is n

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[loy wolfe]

On Wed, Aug 27, 2014 at 3:13 PM, Kevin Benton  wrote:

> Ports are bound in order of configured drivers so as long as the
> OpenVswitch driver is put first in the list, it will bind the ports it can
> and then ODL would bind the leftovers. [1][2] The only missing component is
> that ODL doesn't look like it uses l2pop so establishing tunnels between
> the OVS agents and the ODL-managed vswitches would be an issue that would
> have to be handled via another process.
>
> Regardless, my original point is that the driver keeps the neutron
> semantics and DB in tact. In my opinion, the lack of compatibility with
> l2pop isn't an issue with the driver, but more of an issue with how l2pop
> was designed. It's very tightly coupled to having agents managed by Neutron
> via RPC, which shouldn't be necessary when it's primary purpose is to
> establish endpoints for overlay tunnels.
>

So why not agent based? Neutron shouldn't be treated as just an resource
storage, built-in backends naturally need things like l2pop and dvr for
distributed dynamic topology control,  we couldn't say that something as a
part was "tightly coupled".

On the contrary, 3rd backends should adapt themselves to be integrated into
Neutron as thin as they can, focusing on the backend device control but not
re-implement core service logic duplicated with Neutron . BTW, Ofagent is a
good example for this style.


>
>
> 1.
> https://github.com/openstack/neutron/blob/7f466c8730cfca13f2fb374c80d810929bb8/neutron/plugins/ml2/drivers/mech_agent.py#L53
> 2.
> https://github.com/openstack/neutron/blob/7f466c8730cfca13f2fb374c80d810929bb8/neutron/plugins/ml2/drivers/mechanism_odl.py#L326
>
>
> On Tue, Aug 26, 2014 at 10:05 PM, loy wolfe  wrote:
>
>>
>>
>>
>> On Wed, Aug 27, 2014 at 12:42 PM, Kevin Benton  wrote:
>>
>>> >I think that "opensource" is not the only factor, it's about built-in
>>> vs. 3rd backend. Built-in must be opensource, but opensource is not
>>> necessarily built-in. By my thought, current OVS and linuxbridge are
>>> built-in, but shim RESTful proxy for all kinds of sdn controller should be
>>> 3rd, for they keep all virtual networking data model and service logic in
>>> their own places, using Neutron API just as the NB shell (they can't even
>>> co-work with built-in l2pop driver for vxlan/gre network type today).
>>>
>>>
>>> I understand the point you are trying to make, but this blanket
>>> statement about the data model of drivers/plugins with REST backends is
>>> wrong. Look at the ODL mechanism driver for a counter-example.[1] The data
>>> is still stored in Neutron and all of the semantics of the API are
>>> maintained. The l2pop driver is to deal with decentralized overlays, so I'm
>>> not sure how its interoperability with the ODL driver is relevant.
>>>
>>
>> If we create a vxlan network,  then can we bind some ports to built-in
>> ovs driver, and other ports to ODL driver? linux bridge agnet, ovs agent,
>> ofagent can co-exist in the same vxlan network, under the common l2pop
>> mechanism. By that scenery, I'm not sure whether ODL can just add to them
>> in a heterogeneous multi-backend architecture , or work exclusively and
>> have to take over all the functionality.
>>
>>
>>>
>>> 1.
>>> https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mechanism_odl.py
>>>
>>>
>>>
>>> On Tue, Aug 26, 2014 at 7:14 PM, loy wolfe  wrote:
>>>
 Forwarded from other thread discussing about incubator:

 http://lists.openstack.org/pipermail/openstack-dev/2014-August/044135.html



> Completely agree with this sentiment. Is there a crisp distinction
> between a "vendor" plugin and an "open source" plugin though?
>
>
 I think that "opensource" is not the only factor, it's about built-in
 vs. 3rd backend. Built-in must be opensource, but opensource is not
 necessarily built-in. By my thought, current OVS and linuxbridge are
 built-in, but shim RESTful proxy for all kinds of sdn controller should be
 3rd, for they keep all virtual networking data model and service logic in
 their own places, using Neutron API just as the NB shell (they can't even
 co-work with built-in l2pop driver for vxlan/gre network type today).

 As for the Snabb or DPDKOVS (they also plan to support official qemu
 vhost-user), or some other similar contributions, if one or two of them win
 in the war of this high performance userspace vswitch, and receive large
 common interest, then it may be accepted as built-in.



> The Snabb NFV (http://snabb.co/nfv.html) driver superficially looks
> like a vendor plugin but is actually completely open source. The
> development is driven by end-user organisations who want to make the
> standard upstream Neutron support their NFV use cases.
>
> We are looking for a good way to engage with the upstream community.
> In this cycle we have found kindred spirits in the NFV subteam., but 

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[Kevin Benton]

Ports are bound in order of configured drivers so as long as the
OpenVswitch driver is put first in the list, it will bind the ports it can
and then ODL would bind the leftovers. [1][2] The only missing component is
that ODL doesn't look like it uses l2pop so establishing tunnels between
the OVS agents and the ODL-managed vswitches would be an issue that would
have to be handled via another process.

Regardless, my original point is that the driver keeps the neutron
semantics and DB in tact. In my opinion, the lack of compatibility with
l2pop isn't an issue with the driver, but more of an issue with how l2pop
was designed. It's very tightly coupled to having agents managed by Neutron
via RPC, which shouldn't be necessary when it's primary purpose is to
establish endpoints for overlay tunnels.


1.
https://github.com/openstack/neutron/blob/7f466c8730cfca13f2fb374c80d810929bb8/neutron/plugins/ml2/drivers/mech_agent.py#L53
2.
https://github.com/openstack/neutron/blob/7f466c8730cfca13f2fb374c80d810929bb8/neutron/plugins/ml2/drivers/mechanism_odl.py#L326


On Tue, Aug 26, 2014 at 10:05 PM, loy wolfe  wrote:

>
>
>
> On Wed, Aug 27, 2014 at 12:42 PM, Kevin Benton  wrote:
>
>> >I think that "opensource" is not the only factor, it's about built-in
>> vs. 3rd backend. Built-in must be opensource, but opensource is not
>> necessarily built-in. By my thought, current OVS and linuxbridge are
>> built-in, but shim RESTful proxy for all kinds of sdn controller should be
>> 3rd, for they keep all virtual networking data model and service logic in
>> their own places, using Neutron API just as the NB shell (they can't even
>> co-work with built-in l2pop driver for vxlan/gre network type today).
>>
>>
>> I understand the point you are trying to make, but this blanket statement
>> about the data model of drivers/plugins with REST backends is wrong. Look
>> at the ODL mechanism driver for a counter-example.[1] The data is still
>> stored in Neutron and all of the semantics of the API are maintained. The
>> l2pop driver is to deal with decentralized overlays, so I'm not sure how
>> its interoperability with the ODL driver is relevant.
>>
>
> If we create a vxlan network,  then can we bind some ports to built-in ovs
> driver, and other ports to ODL driver? linux bridge agnet, ovs agent,
> ofagent can co-exist in the same vxlan network, under the common l2pop
> mechanism. By that scenery, I'm not sure whether ODL can just add to them
> in a heterogeneous multi-backend architecture , or work exclusively and
> have to take over all the functionality.
>
>
>>
>> 1.
>> https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mechanism_odl.py
>>
>>
>>
>> On Tue, Aug 26, 2014 at 7:14 PM, loy wolfe  wrote:
>>
>>> Forwarded from other thread discussing about incubator:
>>>
>>> http://lists.openstack.org/pipermail/openstack-dev/2014-August/044135.html
>>>
>>>
>>>
 Completely agree with this sentiment. Is there a crisp distinction
 between a "vendor" plugin and an "open source" plugin though?


>>> I think that "opensource" is not the only factor, it's about built-in
>>> vs. 3rd backend. Built-in must be opensource, but opensource is not
>>> necessarily built-in. By my thought, current OVS and linuxbridge are
>>> built-in, but shim RESTful proxy for all kinds of sdn controller should be
>>> 3rd, for they keep all virtual networking data model and service logic in
>>> their own places, using Neutron API just as the NB shell (they can't even
>>> co-work with built-in l2pop driver for vxlan/gre network type today).
>>>
>>> As for the Snabb or DPDKOVS (they also plan to support official qemu
>>> vhost-user), or some other similar contributions, if one or two of them win
>>> in the war of this high performance userspace vswitch, and receive large
>>> common interest, then it may be accepted as built-in.
>>>
>>>
>>>
 The Snabb NFV (http://snabb.co/nfv.html) driver superficially looks
 like a vendor plugin but is actually completely open source. The
 development is driven by end-user organisations who want to make the
 standard upstream Neutron support their NFV use cases.

 We are looking for a good way to engage with the upstream community. In
 this cycle we have found kindred spirits in the NFV subteam., but we did
 not find a good way to engage with Neutron upstream (see
 https://review.openstack.org/#/c/116476/). It would be wonderful if
 there is a suitable process available for us to use in Kilo e.g. 
 incubation.

 Cheers,
 -Luke

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

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[loy wolfe]

On Wed, Aug 27, 2014 at 12:42 PM, Kevin Benton  wrote:

> >I think that "opensource" is not the only factor, it's about built-in
> vs. 3rd backend. Built-in must be opensource, but opensource is not
> necessarily built-in. By my thought, current OVS and linuxbridge are
> built-in, but shim RESTful proxy for all kinds of sdn controller should be
> 3rd, for they keep all virtual networking data model and service logic in
> their own places, using Neutron API just as the NB shell (they can't even
> co-work with built-in l2pop driver for vxlan/gre network type today).
>
>
> I understand the point you are trying to make, but this blanket statement
> about the data model of drivers/plugins with REST backends is wrong. Look
> at the ODL mechanism driver for a counter-example.[1] The data is still
> stored in Neutron and all of the semantics of the API are maintained. The
> l2pop driver is to deal with decentralized overlays, so I'm not sure how
> its interoperability with the ODL driver is relevant.
>

If we create a vxlan network,  then can we bind some ports to built-in ovs
driver, and other ports to ODL driver? linux bridge agnet, ovs agent,
ofagent can co-exist in the same vxlan network, under the common l2pop
mechanism. By that scenery, I'm not sure whether ODL can just add to them
in a heterogeneous multi-backend architecture , or work exclusively and
have to take over all the functionality.


>
> 1.
> https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mechanism_odl.py
>
>
>
> On Tue, Aug 26, 2014 at 7:14 PM, loy wolfe  wrote:
>
>> Forwarded from other thread discussing about incubator:
>> http://lists.openstack.org/pipermail/openstack-dev/2014-August/044135.html
>>
>>
>>
>>> Completely agree with this sentiment. Is there a crisp distinction
>>> between a "vendor" plugin and an "open source" plugin though?
>>>
>>>
>> I think that "opensource" is not the only factor, it's about built-in vs.
>> 3rd backend. Built-in must be opensource, but opensource is not necessarily
>> built-in. By my thought, current OVS and linuxbridge are built-in, but shim
>> RESTful proxy for all kinds of sdn controller should be 3rd, for they keep
>> all virtual networking data model and service logic in their own places,
>> using Neutron API just as the NB shell (they can't even co-work with
>> built-in l2pop driver for vxlan/gre network type today).
>>
>> As for the Snabb or DPDKOVS (they also plan to support official qemu
>> vhost-user), or some other similar contributions, if one or two of them win
>> in the war of this high performance userspace vswitch, and receive large
>> common interest, then it may be accepted as built-in.
>>
>>
>>
>>> The Snabb NFV (http://snabb.co/nfv.html) driver superficially looks
>>> like a vendor plugin but is actually completely open source. The
>>> development is driven by end-user organisations who want to make the
>>> standard upstream Neutron support their NFV use cases.
>>>
>>> We are looking for a good way to engage with the upstream community. In
>>> this cycle we have found kindred spirits in the NFV subteam., but we did
>>> not find a good way to engage with Neutron upstream (see
>>> https://review.openstack.org/#/c/116476/). It would be wonderful if
>>> there is a suitable process available for us to use in Kilo e.g. incubation.
>>>
>>> Cheers,
>>> -Luke
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> Kevin Benton
>
> ___
> 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

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[Kevin Benton]

>I think that "opensource" is not the only factor, it's about built-in vs.
3rd backend. Built-in must be opensource, but opensource is not necessarily
built-in. By my thought, current OVS and linuxbridge are built-in, but shim
RESTful proxy for all kinds of sdn controller should be 3rd, for they keep
all virtual networking data model and service logic in their own places,
using Neutron API just as the NB shell (they can't even co-work with
built-in l2pop driver for vxlan/gre network type today).


I understand the point you are trying to make, but this blanket statement
about the data model of drivers/plugins with REST backends is wrong. Look
at the ODL mechanism driver for a counter-example.[1] The data is still
stored in Neutron and all of the semantics of the API are maintained. The
l2pop driver is to deal with decentralized overlays, so I'm not sure how
its interoperability with the ODL driver is relevant.

1.
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mechanism_odl.py



On Tue, Aug 26, 2014 at 7:14 PM, loy wolfe  wrote:

> Forwarded from other thread discussing about incubator:
> http://lists.openstack.org/pipermail/openstack-dev/2014-August/044135.html
>
>
>
>> Completely agree with this sentiment. Is there a crisp distinction
>> between a "vendor" plugin and an "open source" plugin though?
>>
>>
> I think that "opensource" is not the only factor, it's about built-in vs.
> 3rd backend. Built-in must be opensource, but opensource is not necessarily
> built-in. By my thought, current OVS and linuxbridge are built-in, but shim
> RESTful proxy for all kinds of sdn controller should be 3rd, for they keep
> all virtual networking data model and service logic in their own places,
> using Neutron API just as the NB shell (they can't even co-work with
> built-in l2pop driver for vxlan/gre network type today).
>
> As for the Snabb or DPDKOVS (they also plan to support official qemu
> vhost-user), or some other similar contributions, if one or two of them win
> in the war of this high performance userspace vswitch, and receive large
> common interest, then it may be accepted as built-in.
>
>
>
>> The Snabb NFV (http://snabb.co/nfv.html) driver superficially looks like
>> a vendor plugin but is actually completely open source. The development is
>> driven by end-user organisations who want to make the standard upstream
>> Neutron support their NFV use cases.
>>
>> We are looking for a good way to engage with the upstream community. In
>> this cycle we have found kindred spirits in the NFV subteam., but we did
>> not find a good way to engage with Neutron upstream (see
>> https://review.openstack.org/#/c/116476/). It would be wonderful if
>> there is a suitable process available for us to use in Kilo e.g. incubation.
>>
>> Cheers,
>> -Luke
>>
>> ___
>> 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
>
>


-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[loy wolfe]

Forwarded from other thread discussing about incubator:
http://lists.openstack.org/pipermail/openstack-dev/2014-August/044135.html



> Completely agree with this sentiment. Is there a crisp distinction between
> a "vendor" plugin and an "open source" plugin though?
>
>
I think that "opensource" is not the only factor, it's about built-in vs.
3rd backend. Built-in must be opensource, but opensource is not necessarily
built-in. By my thought, current OVS and linuxbridge are built-in, but shim
RESTful proxy for all kinds of sdn controller should be 3rd, for they keep
all virtual networking data model and service logic in their own places,
using Neutron API just as the NB shell (they can't even co-work with
built-in l2pop driver for vxlan/gre network type today).

As for the Snabb or DPDKOVS (they also plan to support official qemu
vhost-user), or some other similar contributions, if one or two of them win
in the war of this high performance userspace vswitch, and receive large
common interest, then it may be accepted as built-in.



> The Snabb NFV (http://snabb.co/nfv.html) driver superficially looks like
> a vendor plugin but is actually completely open source. The development is
> driven by end-user organisations who want to make the standard upstream
> Neutron support their NFV use cases.
>
> We are looking for a good way to engage with the upstream community. In
> this cycle we have found kindred spirits in the NFV subteam., but we did
> not find a good way to engage with Neutron upstream (see
> https://review.openstack.org/#/c/116476/). It would be wonderful if there
> is a suitable process available for us to use in Kilo e.g. incubation.
>
> Cheers,
> -Luke
>
> ___
> 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

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[Kyle Mestery]

On Fri, Aug 15, 2014 at 2:26 PM, Kevin Benton  wrote:
> I definitely agree that reviewer time is wasted reviewing changes. However,
> I don't think moving them to a different repo with different cores is going
> to make them less brittle without some very strict guidelines about what a
> driver/plugin is allowed to do.
>
Agreed.

> For example, without neutron core reviewer oversight, what prevents a plugin
> author from monkey patching parts of the neutron API? If nothing, that will
> immediately break on any kind of API refactoring, module renaming, etc.
>
The fact that this will need to be merged in a repo under the
networking program means we would catch this. However, the person who
wants to monkey patch like this could easily move their plugin out of
tree and monkey patch to their hearts content.

> That scenario also brings up another concern. Will changes to neutron that
> break a vendor plugin even be blocked on the neutron side? If so, the
> neutron repo will be held hostage by third-party code that isn't in Neutron
> and lacks the quality control it would have in Neutron. If not, this will
> immediately break the gate on the driver repo, forcing maintainers to
> disable the gating job for that vendor plugin. Neither of these scenarios
> seem less brittle to me.
>
If we had cross-repo CI running (like was suggested for the
incubator), we would catch things like this. In other words, if the
driver repo ran for patches to the neutron repo and posted back, we
could catch this.

> What the PLUMgrid folks did works; however, IIUC it was at the sacrifice of
> unit tests verifying any calls into the plumlib. There is just a fake driver
> that accepts anything for the unit tests. [1] They could implement a lot of
> mock logic to simulate the real driver, but then we are back to square one
> and they might as well put the actual driver there.
>
> I'm all for moving drivers/plugins out of Neutron, but we need to be really
> careful here because we are going to lose a lot of quality control that
> Neutron could end up taking the blame for since these drivers/plugins are
> still in a public repo.
>
++, this is a critical area here. On the other hand, the current model
of adding 5-6 new plugins/drivers for proprietary backends each cycle
won't scale going forward, and the level of involvement of most of
these companies ends at their plugin. So something needs to change to
make this scalable going forward.

Kyle

> 1.
> https://github.com/openstack/neutron/blob/08529376f16837083c28b009411cc52e0e2a8d33/neutron/plugins/plumgrid/drivers/fake_plumlib.py
>
>
> On Fri, Aug 15, 2014 at 8:50 AM, Kyle Mestery  wrote:
>>
>> I think the review time alone is a huge issue. Even worse, for the
>> most part, core reviewers are reviewing code for which they themselves
>> can't test because it requires proprietary hardware or software,
>> making the situation brittle at best. Having a separate git repository
>> which is gated by stringent third-party CI requirements, with separate
>> (and possibly overlapping) core reviewers would help to alleviate this
>> problem. Another alternative is to move most intelligence out of the
>> plugins/drivers and into vendor owned packages which can live on pypi.
>> This is similar to what the PLUMgrid folks did for their plugin. This
>> allows vendor control over most of their bits, removes the constant
>> churn for simple bug fixes in the neutron tree, and adds the benefit
>> of being a part of the simultaneous release, which is the only thing
>> most vendors care about.
>>
>> On Thu, Aug 14, 2014 at 10:34 PM, Kevin Benton  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.
>> >
>> > Can you elaborate on the ways that they are slowing down the velocity? I
>> > know they take up reviewer time, but are there other ways that you think
>> > they slow down the project?
>> >
>> >
>> > On Thu, Aug 14, 2014 at 6:07 AM, Kyle Mestery 
>> > 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
>> >> 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
>> 

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[Shiv Haris]

In case we are going to expand this to plugins and mechanism drivers, we may 
want to consider these ramifications:


1.   how will db migrations take place – currently they are all 
inter-twinned with neutron infra

2.   How does one resolver foreign keys dependencies  between neutron and 
plugin repos

Oops – did I open a can of worms?

-Shiv



From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Thursday, August 14, 2014 3:09 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

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 
mailto:loywo...@gmail.com>> wrote:


On Thu, Aug 14, 2014 at 4:22 PM, Mathieu Rohon 
mailto: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 
mailto: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 
> mailto: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<mailto:OpenStack-dev@lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto: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

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[Kevin Benton]

I definitely agree that reviewer time is wasted reviewing changes. However,
I don't think moving them to a different repo with different cores is going
to make them less brittle without some very strict guidelines about what a
driver/plugin is allowed to do.

For example, without neutron core reviewer oversight, what prevents a
plugin author from monkey patching parts of the neutron API? If nothing,
that will immediately break on any kind of API refactoring, module
renaming, etc.

That scenario also brings up another concern. Will changes to neutron that
break a vendor plugin even be blocked on the neutron side? If so, the
neutron repo will be held hostage by third-party code that isn't in Neutron
and lacks the quality control it would have in Neutron. If not, this will
immediately break the gate on the driver repo, forcing maintainers to
disable the gating job for that vendor plugin. Neither of these scenarios
seem less brittle to me.

What the PLUMgrid folks did works; however, IIUC it was at the sacrifice of
unit tests verifying any calls into the plumlib. There is just a fake
driver that accepts anything for the unit tests. [1] They could implement a
lot of mock logic to simulate the real driver, but then we are back to
square one and they might as well put the actual driver there.

I'm all for moving drivers/plugins out of Neutron, but we need to be really
careful here because we are going to lose a lot of quality control that
Neutron could end up taking the blame for since these drivers/plugins are
still in a public repo.

1.
https://github.com/openstack/neutron/blob/08529376f16837083c28b009411cc52e0e2a8d33/neutron/plugins/plumgrid/drivers/fake_plumlib.py


On Fri, Aug 15, 2014 at 8:50 AM, Kyle Mestery  wrote:

> I think the review time alone is a huge issue. Even worse, for the
> most part, core reviewers are reviewing code for which they themselves
> can't test because it requires proprietary hardware or software,
> making the situation brittle at best. Having a separate git repository
> which is gated by stringent third-party CI requirements, with separate
> (and possibly overlapping) core reviewers would help to alleviate this
> problem. Another alternative is to move most intelligence out of the
> plugins/drivers and into vendor owned packages which can live on pypi.
> This is similar to what the PLUMgrid folks did for their plugin. This
> allows vendor control over most of their bits, removes the constant
> churn for simple bug fixes in the neutron tree, and adds the benefit
> of being a part of the simultaneous release, which is the only thing
> most vendors care about.
>
> On Thu, Aug 14, 2014 at 10:34 PM, Kevin Benton  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.
> >
> > Can you elaborate on the ways that they are slowing down the velocity? I
> > know they take up reviewer time, but are there other ways that you think
> > they slow down the project?
> >
> >
> > On Thu, Aug 14, 2014 at 6:07 AM, Kyle Mestery 
> 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
> >> 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  >
> >> 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.
> >> >
> >> >

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[Daniel P. Berrange]

On Thu, Aug 14, 2014 at 12:09:26PM +0200, Salvatore Orlando 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?)

Note also that there is a communications channel between Nova and Neutron
that has to pass port binding info when plugging VIFs, so that Nova can
configure things in the right way. 

The definition of the valid metadata in this API is not something that
I would consider external plugins to be permitted to extend/change as
it is a semi-public communications channel, not merely an internal
implementation detail. Also note that from Juno onwards Nova no longer
supports out of tree VIF driver implementations because we do not
consider the VIF driver classes to be a public extension point.

So if a Neutron plugin is to live out of tree, it needs to be able to
work with the VIF port binding metadata that is officially supported
in-tree by Neutron & Nova, and with an in-tree Nova VIF driver.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[Kyle Mestery]

I think the review time alone is a huge issue. Even worse, for the
most part, core reviewers are reviewing code for which they themselves
can't test because it requires proprietary hardware or software,
making the situation brittle at best. Having a separate git repository
which is gated by stringent third-party CI requirements, with separate
(and possibly overlapping) core reviewers would help to alleviate this
problem. Another alternative is to move most intelligence out of the
plugins/drivers and into vendor owned packages which can live on pypi.
This is similar to what the PLUMgrid folks did for their plugin. This
allows vendor control over most of their bits, removes the constant
churn for simple bug fixes in the neutron tree, and adds the benefit
of being a part of the simultaneous release, which is the only thing
most vendors care about.

On Thu, Aug 14, 2014 at 10:34 PM, Kevin Benton  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.
>
> Can you elaborate on the ways that they are slowing down the velocity? I
> know they take up reviewer time, but are there other ways that you think
> they slow down the project?
>
>
> On Thu, Aug 14, 2014 at 6:07 AM, Kyle Mestery  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
>> 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 
>> 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  wrote:
>> >>
>> >>
>> >>
>> >>
>> >> On Thu, Aug 14, 2014 at 4:22 PM, Mathieu Rohon
>> >> 
>> >> 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
>> >>> 
>> >>> 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:
>> >>> >
>> >>> >
>> >>>

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[Kevin Benton]

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

Can you elaborate on the ways that they are slowing down the velocity? I
know they take up reviewer time, but are there other ways that you think
they slow down the project?


On Thu, Aug 14, 2014 at 6:07 AM, Kyle Mestery  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
> 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 
> 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  wrote:
> >>
> >>
> >>
> >>
> >> On Thu, Aug 14, 2014 at 4:22 PM, Mathieu Rohon  >
> >> 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 
> >>> > 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.opens

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[loy wolfe]

On Thu, Aug 14, 2014 at 9:07 PM, Kyle Mestery  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 
> 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  wrote:
> >>
> >>
> >>
> >>
> >> On Thu, Aug 14, 2014 at 4:22 PM, Mathieu Rohon  >
> >> 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 
> >>> > 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

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[Kyle Mestery]

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  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  wrote:
>>
>>
>>
>>
>> On Thu, Aug 14, 2014 at 4:22 PM, Mathieu Rohon 
>> 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 
>>> 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 
>>> > 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
>

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[Salvatore Orlando]

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

>
>
>
> On Thu, Aug 14, 2014 at 4:22 PM, Mathieu Rohon 
> 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 
>> 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 
>> 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

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[loy wolfe]

On Thu, Aug 14, 2014 at 4:22 PM, Mathieu Rohon 
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 
> 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 
> 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

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[Mathieu Rohon]

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] https://review.openstack.org/#/c/96459/

On Wed, Aug 13, 2014 at 1:09 PM, Robert Kukura  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  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

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[Robert Kukura]

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

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

[ZZelle]

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  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] [neutron][ml2] Mech driver as out-of-tree add-on

[Dave Tucker]

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] [neutron][ml2] Mech driver as out-of-tree add-on

[Luke Gorrie]

Howdy!

Rumor has it that it's easy to distribute ML2 mech drivers as out-of-tree
add-on modules.

Is this true? Has it been done? Where would one find an example?

Cheers!
-Luke
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev