Open Stack

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 <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
> 
> > 
> > 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev