Open Stack

On 30 April 2016 at 14:24, 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.
>

It's my intention to follow up with a formal spec submission to
neutron-specs as soon as I recover from the trip. Then you'll have a more
transparent place to voice your concern.


>
> 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:
>

It's not just about burden. It's about consistency first and foremost.


>
> Quoting the etherpad [1]
>
> "No request for inclusion are accepted for projects focussed solely on
> implementations and/or API extensions to non-open solutions."
>

By the way, this was brought forward and discussed way before the Summit.
In fact this is already implemented at the Neutron governance level [1].


> 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”.
>

Totally false.

All this means is that these projects do not show up in list [1] (minus
[2], which I forgot): ie. these projects are the projects the Neutron team
vouches for. Supportability is not a property tracked by this list. You,
amongst many, should know that it takes a lot more than being part of a
list to be considered a supported solution, and I am actually even
surprised that you are misled/misleading by bringing 'support' into this
conversation.

[1] http://governance.openstack.org/reference/projects/neutron.html
[2] https://review.openstack.org/#/c/309618/


>
> 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.
>

Again, totally false.

The Neutron team will continue to stand behind the APIs and integration
mechanisms in a way that made the journey of breaking down the codebase as
we know it today possible. Any discussion of evolving these has been done
and will be done in the open and with the support of all parties involved,
non-open solutions included.


>
> 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.
>

What? Now you're just spreading FUD.

What is being discussed in that etherpad is totally in line with [1], which
you approved and stood behind, by the way! No-one is breaking anything,
we're simply better reflecting what initiatives the Neutron core team is
supposed to be accountable for and, as a result, empower the individual
core teams of those vendor drivers. I appreciate there might be a gap in
where to describe the effort of these initiatives in [2], but I believe
there's something like the marketplace [3] that's better suited for what
you're after. IMO, [2] was never intended to be that place, and I stand
corrected if not.

[1] https://review.openstack.org/#/c/309618/
[2] http://governance.openstack.org/
[3] https://www.openstack.org/marketplace/drivers/


> 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.
>

Every project is different, comparing Nova to Neutron or Cinder etc is not
a like-for-like comparison.


>
> 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.
>

As as I said, this is not about support. Solutions will continue to work
(well or badly) as they used to, even if they are no longer part of that
list.


> 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.
>

As I said earlier, it's my intention to follow up with a formal spec
submission to neutron-specs so that we can all better articulate thoughts,
and get to a more formal closure/consensus.


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