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

Gal Sagie gal.sagie at gmail.com
Mon May 2 19:18:52 UTC 2016


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

> On Mon, May 2, 2016 at 12:22 PM, Armando M. <armamig at gmail.com> wrote:
> >
> >
> > 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/
> >
> 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
> >> [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
> >
>
> __________________________________________________________________________
> 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
>



-- 
Best Regards ,

The G.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160502/e6b19aed/attachment.html>


More information about the OpenStack-dev mailing list