Forwarded from other thread discussing about incubator:

> 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 ( 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
> 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
OpenStack-dev mailing list

Reply via email to