On Wed, Aug 27, 2014 at 12:42 PM, Kevin Benton <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Kevin Benton > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
