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

Kevin Benton blak111 at gmail.com
Wed Aug 27 04:42:08 UTC 2014


>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 <loywolfe at gmail.com> 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 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
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140826/95a304fc/attachment.html>


More information about the OpenStack-dev mailing list