[openstack-dev] [neutron][tc] Neutron stadium evolution from Austin

Fawad Khaliq fawad at plumgrid.com
Sat Apr 30 19:24:01 UTC 2016

Hi folks,

Hope everyone had a great summit in Austin and got back safe! :)

At the design summit, we had a Neutron stadium evolution session, which
needs your immediate attention as it will impact many stakeholders of

To summarize for everyone, our Neutron leadership made the following
proposal for the “greater-good” of Neutron to improve and reduce burden on
the Neutron PTL and core team to avoid managing more Neutron drivers:

Quoting the etherpad [1]

"No request for inclusion are accepted for projects focussed solely on
implementations and/or API extensions to non-open solutions."

To summarize for everyone what this means is that all Neutron drivers,
which implement non open source networking backends are instantly out of
the Neutron stadium and are marked as "unofficial/unsupported/remotely
affiliated" and rest are capable of being tagged as "supported/official”.

This eliminates all commercial Neutron drivers developed for many service
providers and enterprises who have deployed OpenStack successfully with
these drivers. It’s unclear how the OpenStack Foundation will communicate
its stance with all the users but clearly this is a huge set back for
OpenStack and Neutron. Neutron will essentially become closed to all
existing, non-open drivers, even if these drivers have been compliant with
Neutron API for years and users have them deployed in production, forcing
users to re-evaluate their options.

Furthermore, this proposal will erode confidence in Neutron and OpenStack,
and destroy much of the value that the community has worked so hard to
build over the years.

As a representative and member of the OpenStack community and maintainer of
a Neutron driver (since Grizzly), I am deeply disappointed and disagree
with this statement [2]. Tossing out all the non-open solutions is not in
the best interest of the end user companies that have built working
OpenStack clusters. This proposal will lead OpenStack end users who
deployed different drivers to think twice about OpenStack communities’
commitment to deliver solutions they need. Furthermore, this proposal
punishes OpenStack companies who developed commercial backend drivers to
help end users bring up OpenStack clouds.

Also, we have to realize that this proposal divides the community rather
than unifying it. If it proceeds, it seems all OpenStack projects should
follow for consistency. For example, this should apply to Nova which means
HyperV and vShphere can't be part of Nova, PLUMgrid can't be part of Kuryr,
and ABC company cannot have a driver/plugin for a XYZ project.

Another thing to note is, for operators, the benefit is that the
flexibility up until now has allowed them to embark on successful OpenStack
deployments. For those operators, yanking out support they’ve come to
depend on makes things worse. While certain team members may prefer only
open-source technology, it’s better to let the end users make that decision
in the free competition of the marketplace without introducing notion of
official/supported vs unofficial/unsupported drivers purely based on
open-source nature of the driver backend despite having complete compliance
with the OpenStack ecosystem.

So if the Neutron PTL is over burdened, we should all help him somehow so
he does not have to make decisions and solve problems in a way that
OpenStack community breaks like this.

I hope we see people offer ideas, time to help and discuss this and that
our Neutron leadership understands the points I am raising and we can avoid
going towards such a route to prevent Neutron, OpenStack, and its ecosystem
from expanding so we continue to see "one" OpenStack community with one
open API.

[2] "No request for inclusion are accepted for projects focussed solely on
implementations and/or API extensions to non-open solutions."

Fawad Khaliq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160430/805d3966/attachment.html>

More information about the OpenStack-dev mailing list