<div dir="ltr"><div style="font-family:arial,sans-serif;font-size:12.727272033691406px">Forwarded from other thread discussing about incubator:</div><div style><font face="arial, sans-serif"><a href="http://lists.openstack.org/pipermail/openstack-dev/2014-August/044135.html">http://lists.openstack.org/pipermail/openstack-dev/2014-August/044135.html</a></font><br>
</div><div style><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>
<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>