Open Stack

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/7f466c8730cfca13f2fb374c80d810929bb8cccc/neutron/plugins/ml2/drivers/mech_agent.py#L53
2.
https://github.com/openstack/neutron/blob/7f466c8730cfca13f2fb374c80d810929bb8cccc/neutron/plugins/ml2/drivers/mechanism_odl.py#L326


On Tue, Aug 26, 2014 at 10:05 PM, loy wolfe <loywolfe at gmail.com> wrote:

>
>
>
> On Wed, Aug 27, 2014 at 12:42 PM, Kevin Benton <blak111 at gmail.com> 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 <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
>>
>> _______________________________________________
>> 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/20140827/8a0f8c50/attachment.html>