Open Stack

Excerpts from Armando M.'s message of 2015-12-08 22:46:16 -0800:
> 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
> "stadium"
> 
> 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

This is the thing that's key, for me. As Anita points out elsewhere in
this thread, we want to structure our project teams so that decision
making and responsibility are placed in the same set of hands. It sounds
like the Stadium concept has made it easy to let those diverge.

> 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,
> plugins/drivers).
> 
> 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??)

>From a technical perspective, if there is a stable API for driver
plugins, having the driver managed outside of the core team shouldn't
be a problem. If there's no stable API, the driver shouldn't even
be outside of the core repository yet. I know the split has happened,
I don't know how stable the plugin APIs are, though.

>From a governance perspective, I agree it is desirable to enable
(but not require) drivers to live outside of core. But see the previous
paragraph for caveats.

> 
> > dhellmann: we have previously said that projects run by different teams
> talk to each other over rest interfaces as a way of clearly delineating
> boundaries
> 
> 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.

Right, I think what we're saying is that you should stop treating
these things as extensions. There are true technical issues introduced
by the need to have strong API guarantees to support out-of-tree
extensions.  As Sean mentioned in his response, the TC and community
want projects to have stable, fixed, APIs that do not change based
on deployment choices, so it is easy for users to understand the
API and so we can enable interoperability between deployments.
DefCore depends on these fixed APIs because of the way tests from
the Tempest suite are used in the validation process. Continuing
to support extensions in Neutron is going to make broad adoption
of Neutron APIs for DefCore harder.

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

It needs to be possible to build on top of neutron without injecting
yourself into the guts of neutron at runtime. See above.

Doug

> 
> 
> 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.
> 
> Cheers,
> Armando
> 
> [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
> >
> >