Open Stack

On 12/09/2015 01:46 AM, Armando M. wrote:
> 
> 
> On 3 December 2015 at 02:21, Thierry Carrez <thierry at openstack.org
> <mailto: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>
>     > <mailto: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 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: Iattempted 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??)

Armando, definitely agree with you. I think that the first step is
probably declaring what the core team believes they can vouch for in the
governance repo. Any drivers that are outside of that need to be
responsible for their own release and install mechanism. I think the
current middle ground means that no one is responsible for their release
/ install mechanism. Which is bad for everyone.

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

Over a 3 year period, what's the cost of not doing it? Both in code dept
and friction, as well as opportunity cost to have more interesting
services build of these APIs. You and the neutron team would know better
than I, but it's worth considering the flip side as well.

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

Changing the REST API isn't innovation, it's incompatibility for end
users. If we're ever going to have compatible clouds and a real interop
effort, the APIs for all our services need to be very firmly controlled.
Extending the API arbitrarily should be a deprecated concept across
OpenStack.

Otherwise, I have no idea what the neutron (or any other project) API is.

	-Sean

-- 
Sean Dague
http://dague.net