Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140827/7b2ecc42/attachment.html>