Open Stack

On Mon, May 2, 2016 at 3: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.

Well said. This came up multiple times in the Gerrit discussion(s) a
couple of months back. The design summit discussion highlighted again
that people don't know what the stadium is (The usage of the word
'supported' or 'official' really demonstrates this. Supported by
who?).

The stadium is not a lot more than perception at this point. What I'd
like to do is realign the terminology we use to describe networking
projects.

Can we consider a stadium project as an 'assisted' project, and a
project outside of the stadium as an 'independent' project? I'd like
to avoid using terms that reflect poorly on projects outside of the
stadium, and reverse the situation: Let's refer to projects outside
the stadium using either a neutral or a positive word, and be
consistent about using that word in any public facing document. I
would normally avoid debating semantics, but since these days the
stadium is more about perception than anything else, I think we should
focus on semantics and explaining what the stadium exactly is.

Another thing we should ask ourselves is the existence of the stadium.
The idea that the Neutron team can vouch for a project is insane to
me. Neutron cores cannot vouch for ODL, only ODL developers can vouch
for ODL. For my money, Neutron cores currently do not vouch for
anything other than Neutron anyway, so this is just about reflecting
reality, not performing any real changes. The only sticking point I
see (And here I definitely agree with Armando) from a governance point
of view is the ability to have control over OpenStack's networking API
(It's conceivable to have the people with control over OpenStack's
networking API to be different than the current group of Neutron
cores). If we're OK going forward with no centralized place to manage
networking projects, we're also OK with having no control over the
API, and the danger here is to allow new projects (Think SFC and
SFC-new 6 months later) that solve similar use cases to define their
own API. That seems counter productive to OpenStack's longevity. One
way to resolve this is to go forward with Armando's suggestion to have
a centralized location to discuss and approve new APIs. I'm not sure
we must enforce the API declarations via some technical mechanism, it
might be possible to have everything on paper instead and assume
people are generally decent. Note that control over the API and the
stadium are essentially two independent problems, it may be convenient
to tackle both under the stadium discussion, but it's not necessary.

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