Open Stack

> On Nov 30, 2015, at 10:15 PM, Armando M. <armamig at gmail.com> wrote:
> 
> 
> 
> On 30 November 2015 at 20:47, Doug Wiegley <dougwig at parksidesoftware.com <mailto:dougwig at parksidesoftware.com>> wrote:
> 
>> On Nov 30, 2015, at 5:56 PM, Armando M. <armamig at gmail.com <mailto:armamig at gmail.com>> wrote:
>> 
>> Hi folks,
>> 
>> The stadium concept was introduced more or less formally since April of this year. At the time it was introduced (see [1]), the list of deliverables included neutron, client, specs and *-aas services. As you may be well aware, 6+ months is a long time in the OpenStack world, and lots of things happened since then. The list has grown to [2]. 
>> 
>> When I think about what 'deliverables' are, I am inclined to think that all of the projects that are part of the list will have to behave and follow the same rules, provided that there is flexibility given by the tags. However, reality has proven us that rules are somewhat difficult to follow and enforce, and some boundaries may be too strict for some initiatives to comply with. This is especially true if we go from a handful of projects that we had when this had started to the nearly the two dozens we have now.
>> As a result, there is quite an effort imposed on the PTL, the various liaisons (release, infra, docs, testing, etc) and the core team to help manage the existing relationships and to ensure that the picture stays coherent over time. Sometimes the decision of being part of this list is even presented before one can see any code, and that defeats the whole point of the deliverable association. I have experienced first hand that this has become a burden, and I fear that the stadium might be an extra layer of governance/complexity that could even interfere with the existing responsibilities of the TC and of OpenStack infra.
>> 
>> So my question is: would revisiting/clarifying the concept be due after some time we have seen it in action? I would like to think so. To be fair, I am not sure what the right answer is, but I know for a fact that some iterations are in order, and I like to make a proposal:
>> 
>> I would like to suggest that we evolve the structure of the Neutron governance, so that most of the deliverables that are now part of the Neutron stadium become standalone projects that are entirely self-governed (they have their own core/release teams, etc). In order to denote the initiatives that are related to Neutron I would like to present two new tags that projects can choose to label themselves with:
>> 
> 
> Interesting proposal, and I’m just thinking out loud here. I’m generally in favor of separating the governance as we separate the dependencies, just because at some point what we’re doing doesn’t scale. To provide a little context, there are two points worth keeping in mind:
> 
> - The neutron stadium actually slightly pre-dates the big tent, and works around some earlier governance friction. So it may make less sense now in light of those changes.
> 
> If my memory doesn't fail me, the first time I recall of talks about the big tent is September 2014, in this email thread:
> 
> http://lists.openstack.org/pipermail/openstack-dev/2014-September/046437.html <http://lists.openstack.org/pipermail/openstack-dev/2014-September/046437.html>
> 
> So, no I don't think we were a novelty :)
>  
> 
> - Many of the neutron subprojects *MUST RELEASE IN LOCKSTEP WITH NEUTRON* to be useful. These items are less useful to be considered standalone, as they need general oversight, co-gating, and such, to stay sane. As we break the massive coupling that exists, this point will get less and less relevant. 
> 
> I don't think that requires the oversight of a single individual, but you're right that this point will fade away over time.
>  
> 
> - I think that part of the initial intent was that these small subprojects would have their own core teams, but be able to take advantage of the infrastructure that exists around neutron as a whole (specs, release team, stable team, co-gates, mentors).
> 
> For your proposal, are you suggesting:
> 
> 1. That these projects are fully separate, with their own PTLs and everything, and just have tags that imply their neutron dependency?  OR,
> 
> My point is: the project decides what's best, I don't have to have an opinion :)

I don’t think you *have* to have an opinion in either scheme. That sounds self-imposed. Delegate it.

> 
> If they want to signal a relationship with Neutron they can do so by choosing one of the two tags being proposed.
>  
> 2. That they stay stadium projects, but we use tags to differentiate them? Many already have different core teams and their own specs process.
> 
> Must there be a place where we are together that is not OpenStack already? And what would that together mean exactly? That's the conundrum I am trying to move away from....
>  
> 
> Are there particular projects that add more overhead? Does your proposal make it easier to get code to our user base? Does it add a bunch of makework to fit into a new model (same question, really). Is the PTL overhead too high currently? Is the shed pink or blue?  :-)
> 
> Not sure what you're asking: this isn't just about overhead to a single or a small group of people. It's about arranging ourselves the best way possible in order to deal with growth: if there were to be an upper limit to the amount of projects we have to deal with, then things would be easier to predict and manage, but we're far from having that in sight, I think.

Right, I’m asking you what the day-to-day pain points are *today* from your perspective. Because we don’t see them the way that you do, and it’s very hard to evaluate what makes sense for growth without knowing the actual constraints. I’m interested in what’s not working, or where you see load increasing.

We expected some release team efficiency with subprojects, is that not what we’re seeing? 

We expected mostly separate core teams that wouldn’t impact neutron, are we seeing something different? 

When we kicked drivers/plugins out of tree, we offered an “official” openstack repo to the tiny single dev drivers that likely wouldn’t make it in the tent; has that offer/desire changed?

I expect that the launchpad/bug load might be increasing linearly; that joint bug bucket might not make any sense, regardless of the decision here.

Do we envision an evolution of things splitting as they get bigger, or just blowing the concept up and going back to experimental or tent?

>> 'use-neutron-system': this means that the project provides networking services by using a pre-deployed end-to-end neutron system as is. No modifications whatsoever.
I think this one might be covered by requirements.txt.

Thanks,
doug


>  
> 
> Thanks,
> doug
> 
> 
> 
> 
>> 
>> 'is-neutron-subsystem': this means that the project provides networking services by implementing an integral part (or parts) of an end-to-end neutron system. Examples are: a service plugin, an ML2 mech driver, a monolithic plugin, an agent etc. It's something an admin has to use in order to deploy Neutron in a certain configuration.
>> 'use-neutron-system': this means that the project provides networking services by using a pre-deployed end-to-end neutron system as is. No modifications whatsoever.
>> 
>> As a result, there is no oversight by the Neutron core team, the PTL or liasons, but that should not stop people from being involved if they choose to. We would not lose the important piece of information which is the association to Neutron, and at the same time that would relieve some of us from the onus of dealing with initiatives for which we lack enough context and ability of providing effective guidance.
>> 
>> In the process, the core team should stay focused on breaking the coupling that still affects Neutron so that projects that depend on it can do so more reliably, and yet innovate more independently. If that means revisiting the Neutron's mission statement, we can discuss that too.
>> 
>> I am sure this hardly covers all the questions you may have at this point, but I would like to take the opportunity to start the conversation to see where people stand. Whichever the outcome, I think that we should strive for decentralizing responsibilities as much as we can in order to be scalable as a project and I think that the current arrangement prevents us from doing that.
>> 
>> Thanks for reading.
>> 
>> Armando 
>> 
>> 
>> [1] https://github.com/openstack/governance/blob/april-2015-elections/reference/projects.yaml#L141 <https://github.com/openstack/governance/blob/april-2015-elections/reference/projects.yaml#L141>
>> [2] https://github.com/openstack/governance/blob/master/reference/projects.yaml#L2000 <https://github.com/openstack/governance/blob/master/reference/projects.yaml#L2000>__________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <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://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <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 <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <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/20151130/3153e43e/attachment.html>