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 <[email protected]> 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 <[email protected]> wrote: >> >> >> >> >> On Wed, Aug 27, 2014 at 3:13 PM, Kevin Benton <[email protected]> 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/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 <[email protected]> wrote: >>>> >>>> >>>> >>>> >>>> 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 >>>> >>> >>> >>> >>> -- >>> 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 >> > > > > -- > 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
