On 30 April 2016 at 15:42, Doug Wiegley <doug...@parksidesoftware.com> 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 > ++ Thanks Doug, this is very well elaborated. I am gonna steal that in my spec :) > > > > 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
