I have to agree with Doug. This proposal isn't saying you can't have a neutron plugin/driver, it's just that it won't be under governance of neutron. As long as the plugin and driver interfaces are there and relatively stable, you'll be able to use it. Also, if I understood correctly, you'll also be able to continue having a repository for your plugin/driver in the openstack namespace. Combine that with everything else Doug said, it seems fairly logical unless I've missed something.
Thanks, Brandon On Sat, 2016-04-30 at 14:42 -0600, Doug Wiegley wrote: > > > On Apr 30, 2016, at 1:24 PM, Fawad Khaliq <fa...@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 > > > > > 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? > > > Thanks, > doug > > > > > > > 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 > > [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-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev