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

Doug Wiegley dougwig at parksidesoftware.com
Sat Apr 30 20:42:37 UTC 2016

> On Apr 30, 2016, at 1:24 PM, Fawad Khaliq <fawad at plumgrid.com> wrote:
> 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 Neutron.
> 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.”

Let’s be clear about official openstack projects versus in the ecosystem versus whatever, which is defined by the TC, not neutron: https://governance.openstack.org/reference/new-projects-requirements.html <https://governance.openstack.org/reference/new-projects-requirements.html>
> 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”.

So, before we throw around statements like “supported” vs “unsupported”, let’s take a look at what the stadium governance change really entails:

- The neutron core team won’t review/merge/maintain patches for your plugin/driver. In many cases, this was already true.
- The neutron release team won’t handle tagging your releases. In many cases, this was already true.
- The neutron PTL is no longer involved in your repository’s governance. In many cases, this was effectively already true.

It doesn’t mean it isn’t a valid project that supports neutron interfaces.

In or out of the stadium, all plugins have these challenges:

- If you’re not using a stable interface, you’ll break a lot.
- If you are using a stable interface, you’ll still break some (standard rot).
- Vendors will need to support and test their own code.

Every time this comes up, people get upset that neutron is closing its doors, or somehow invalidating all the existing plugins. Let’s review:

- The neutron api and plugin interfaces are not going away.
- There is ongoing work to libify more interfaces, for the sake of plugins/drivers.
- There is a strong push for more documentation to make integrating better.
- Non-stadium projects still have access to their infra repos and CI resources.

Armando’s proposal was about recognizing reality, not some huge change in how things actually work. What is the point of having a project governed by Neutron that isn’t doing anything but consuming neutron interfaces, and is otherwise uninvolved? How can you expect neutron to vouch for those? What is your proposal?


> 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.
> [1] https://etherpad.openstack.org/p/newton-neutron-community-stadium-evolution <https://etherpad.openstack.org/p/newton-neutron-community-stadium-evolution>
> [2] "No request for inclusion are accepted for projects focussed solely on implementations and/or API extensions to non-open solutions."
> Thanks,
> Fawad Khaliq
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

More information about the OpenStack-dev mailing list