<div dir="ltr">><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>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><br></div><div>1. <a href="https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mechanism_odl.py">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"><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:0 0 0 .8ex;border-left:1px #ccc 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 class="">
<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">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>