<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 27, 2014 at 3:13 PM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">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. <div>
<br></div><div>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.</div>
</div></blockquote><div><br></div><div>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". </div>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div><br><div><div><br></div><div>1. <a href="https://github.com/openstack/neutron/blob/7f466c8730cfca13f2fb374c80d810929bb8cccc/neutron/plugins/ml2/drivers/mech_agent.py#L53" target="_blank">https://github.com/openstack/neutron/blob/7f466c8730cfca13f2fb374c80d810929bb8cccc/neutron/plugins/ml2/drivers/mech_agent.py#L53</a></div>
<div>2. <a href="https://github.com/openstack/neutron/blob/7f466c8730cfca13f2fb374c80d810929bb8cccc/neutron/plugins/ml2/drivers/mechanism_odl.py#L326" target="_blank">https://github.com/openstack/neutron/blob/7f466c8730cfca13f2fb374c80d810929bb8cccc/neutron/plugins/ml2/drivers/mechanism_odl.py#L326</a></div>
</div></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 26, 2014 at 10:05 PM, loy wolfe <span dir="ltr"><<a href="mailto:loywolfe@gmail.com" target="_blank">loywolfe@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div>On Wed, Aug 27, 2014 at 12:42 PM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>><span style="font-family:arial,sans-serif;font-size:13px">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).</span><div>
<span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><br></div></div><div>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. </div>
</div></blockquote><div><br></div></div><div>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.</div>
<div><div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div><br></div><div>1. <a href="https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mechanism_odl.py" target="_blank">https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mechanism_odl.py</a></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></div><div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Tue, Aug 26, 2014 at 7:14 PM, loy wolfe <span dir="ltr"><<a href="mailto:loywolfe@gmail.com" target="_blank">loywolfe@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,sans-serif;font-size:12.727272033691406px">
Forwarded from other thread discussing about incubator:</div>
<div><font face="arial, sans-serif"><a href="http://lists.openstack.org/pipermail/openstack-dev/2014-August/044135.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-August/044135.html</a></font><br>
</div><div><br></div><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><span><font color="#888888"><div><br></div><div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.727272033691406px">Completely agree with this sentiment. Is there a crisp distinction between a "vendor" plugin and an "open source" plugin though?</div>
<div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.727272033691406px"><br></div></div></font></span></div></blockquote><div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span><font color="#888888"><div>
<div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.727272033691406px"></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.727272033691406px">The Snabb NFV (<a href="http://snabb.co/nfv.html" target="_blank">http://snabb.co/nfv.html</a>) 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.</div>
<div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.727272033691406px"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.727272033691406px">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 <a href="https://review.openstack.org/#/c/116476/" target="_blank">https://review.openstack.org/#/c/116476/</a>). It would be wonderful if there is a suitable process available for us to use in Kilo e.g. incubation.</div>
<div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.727272033691406px"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.727272033691406px">Cheers,<br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.727272033691406px">
-Luke</div></div></font></span></div><div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></div></blockquote></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div>Kevin Benton</div>
</font></span></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div></div></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Kevin Benton</div>
</div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>