[openstack-dev] [Neutron] Evolving the stadium concept

Armando M. armamig at gmail.com
Wed Dec 9 06:46:16 UTC 2015

On 3 December 2015 at 02:21, Thierry Carrez <thierry at openstack.org> wrote:

> Armando M. wrote:
> > On 2 December 2015 at 01:16, Thierry Carrez <thierry at openstack.org
> > <mailto:thierry at openstack.org>> wrote:
> >>     Armando M. wrote:
> >>     >> One solution is, like you mentioned, to make some (or all) of
> them
> >>     >> full-fledged project teams. Be aware that this means the TC
> would judge
> >>     >> those new project teams individually and might reject them if we
> feel
> >>     >> the requirements are not met. We might want to clarify what
> happens
> >>     >> then.
> >>     >
> >>     > That's a good point. Do we have existing examples of this or
> would we be
> >>     > sailing in uncharted waters?
> >>
> >>     It's been pretty common that we rejected/delayed applications for
> >>     projects where we felt they needed more alignment. In such cases,
> the
> >>     immediate result for those projects if they are out of the Neutron
> >>     "stadium" is that they would fall from the list of official
> projects.
> >>     Again, I'm fine with that outcome, but I want to set expectations
> >>     clearly :)
> >
> > Understood. It sounds to me that the outcome would be that those
> > projects (that may end up being rejected) would show nowhere on [1], but
> > would still be hosted and can rely on the support and services of the
> > OpenStack community, right?
> >
> > [1] http://governance.openstack.org/reference/projects/
> Yes they would still be hosted on OpenStack development infrastructure.
> Contributions would no longer count toward ATC status, so people who
> only contribute to those projects would no longer be able to vote in the
> Technical Committee election. They would not have "official" design
> summit space either -- they can still camp in the hallway though :)

Hi folks,

For whom of you is interested in the conversation, the topic was brought
for discussion at the latest TC meeting [1]. Unfortunately I was unable to
join, however I would like to try and respond to some of the comments made
to clarify my position on the matter:

> ttx: the neutron PTL say he can't vouch for anything in the neutron

To be honest that's not entirely my position.

The problem stems from the fact that, if I am asked what the stadium means,
as a PTL I can't give a straight answer; ttx put it relatively well (and I
quote him): by adding all those projects under your own project team, you
bypass the Technical Committee approval that they behave like OpenStack
projects and are produced by the OpenStack community. The Neutron team
basically vouches for all of them to be on par. As far as the Technical
Committee goes, they are all being produced by the same team we originally
blessed (the Neutron project team).

The reality is: some of these projects are not produced by the same team,
they do not behave the same way, and they do not follow the same practices
and guidelines. For the stadium to make sense, in my humble opinion, a
definition of these practices should happen and enforcement should follow,
but who's got the time for policing and enforcing eviction, especially on a
large scale? So we either reduce the scale (which might not be feasible
because in OpenStack we're all about scaling and adding more and more and
more), or we address the problem more radically by evolving the
relationship from tight aggregation to loose association; this way who
needs to vouch for the Neutron relationship is not the Neutron PTL, but the
person sponsoring the project that wants to be associated to Neutron. On
the other end, the vouching may still be pursued, but for a much more
focused set of initiatives that are led by the same team.

> russellb: I attempted to start breaking down the different types of repos
that are part of the stadium (consumer, api, implementation of technology,

The distinction between implementation of technology, plugins/drivers and
api is not justified IMO because from a neutron standpoint they all look
like the same: they leverage the pluggable extensions to the Neutron core
framework. As I attempted to say: we have existing plugins and drivers that
implement APIs, and we have plugins that implement technology, so the extra
classification seems overspecification.

> flaper87: I agree a driver should not be independent

Why, what's your rationale? If we dig deeper, some drivers are small code
drops with no or untraceable maintainers. Some are actively developed and
can be fairly complex. The spectrum is pretty wide. Either way, I think
that preventing them from being independent in principle may hurt the ones
that can be pretty elaborated, and the ones that are stale may hurt
Neutron's reputation because we're the ones who are supposed to look after
them (after all didn't we vouch for them??)

> dhellmann: we have previously said that projects run by different teams
talk to each other over rest interfaces as a way of clearly delineating

As much as I agree wholeheartedly with this statement (which I made myself
during the GBP/Neutron saga), it's unrealistic to convert the interface
between Neutron and its extension mechanisms to be purely restful,
especially for the price that will have to be paid in the process.

> sdague: I don't think anything should be extending the neutron API that
isn't controlled by the neutron core team.

The core should be about the core, why would what's built on top be
controlled by the core? By comparison, it's like saying a SIG on the
physical layer of the OSI stack dictates what a SIG on the session layer
should do. It stifles innovation and prevents problems from being solved by
the right domain experts.

That's all I managed to process whilst reading the log. I am sure I missed
some important comments and I apologize for not replying to them; one thing
I didn't miss for sure was all the hugging :)

Thanks for acknowledging the discussion and the time and consideration
given during the TC meeting.


[1] http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-12-08-20.01.html

> --
> Thierry Carrez (ttx)
> __________________________________________________________________________
> 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/20151208/c7769f74/attachment.html>

More information about the OpenStack-dev mailing list