Open Stack

On 9 December 2015 at 06:25, Doug Hellmann <doug at doughellmann.com> wrote:

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

Yes, only during this conversation (and whilst I have been thinking about
this) this has been become suddenly clear.


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

The point is valid, but the motivation behind me raising this thread didn't
stem from a broken interface amongst projects (not primarily anyway).


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

Point taken. To rephrase, the extension mechanisms I was referring to in
the previous paragraph were plugins and drivers, and those implement a
fixed API (the L2/L3 API). However, you're absolutely right: we still have
a loophole we have to close in on it ([1]): as much I would love for it to
be a priority, it doesn't seem there's much appetite to take it on though.

As for DefCore, the journey I would like to take for the project would be
to revise the scope for Neutron, and that should hopefully help adoption.
The road is long and windy though, and I'd need support from the Neutron
core team.

[1]
http://specs.openstack.org/openstack/neutron-specs/specs/liberty/microversioning.html


>
> >
> > > 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
> > >
> > >
>
> __________________________________________________________________________
> 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/20151209/2c3b2dae/attachment.html>