Open Stack

On 30 April 2016 at 15:42, Doug Wiegley <dougwig at parksidesoftware.com>
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
>

++

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-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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160502/a138963b/attachment.html>