Open Stack

Armando has submitted the proposal on Gerrit [1]. Let's take the discussion
there.

[1] https://review.openstack.org/#/c/312199/7

Fawad Khaliq


On Tue, May 3, 2016 at 2:37 AM, Doug Wiegley <dougwig at parksidesoftware.com>
wrote:

> 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> 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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>> 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
>
>
>
> __________________________________________________________________________
> 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/20160506/f120a29a/attachment.html>