[openstack-dev] [neutron][tc] Neutron stadium evolution from Austin

Doug Wiegley dougwig at parksidesoftware.com
Mon May 2 21:37:21 UTC 2016


Were we looking at the same etherpad?  I think the ‘inclusion criteria’ and ‘benefits of the proposal’ sections cover those two points. Are you referring to something else?

Thanks,
doug


> On May 2, 2016, at 12:18 PM, Gal Sagie <gal.sagie at gmail.com> wrote:
> 
> Maybe it can help if instead of trying to define criteria to which projects dont fit into
> the stadium, try to define in your spec what IT IS, and for what purpose its there.
> 
> 
> On Mon, May 2, 2016 at 8:53 PM, Kyle Mestery <mestery at mestery.com <mailto:mestery at mestery.com>> wrote:
> On Mon, May 2, 2016 at 12:22 PM, Armando M. <armamig at gmail.com <mailto:armamig at gmail.com>> wrote:
> >
> >
> > On 30 April 2016 at 14:24, Fawad Khaliq <fawad at plumgrid.com <mailto: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 <http://governance.openstack.org/reference/projects/neutron.html>
> > [2] https://review.openstack.org/#/c/309618/ <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/ <https://review.openstack.org/#/c/309618/>
> > [2] http://governance.openstack.org/ <http://governance.openstack.org/>
> > [3] https://www.openstack.org/marketplace/drivers/ <https://www.openstack.org/marketplace/drivers/>
> >
> To further support Armando here, I agree that the marketplace is the
> best place to host these drivers. In fact, Thierry and I briefly
> discussed this, and I think advocating for the Foundation to help put
> in place more of a specific drivers program and manage it makes a lot
> of sense, especially as most of the benefits both developers and users
> are looking for here are more around marketing and consistency.
> 
> Thanks,
> Kyle
> 
> >>
> >> 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 <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://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <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://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <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://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
> 
> -- 
> Best Regards ,
> 
> The G.
> __________________________________________________________________________
> 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/d2470b7c/attachment.html>


More information about the OpenStack-dev mailing list