Open Stack

On 30 November 2015 at 20:47, Doug Wiegley <dougwig at parksidesoftware.com>
wrote:

>
> On Nov 30, 2015, at 5:56 PM, Armando M. <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

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 :)

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.


>
> 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
> [2]
> 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?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/20151130/817951d3/attachment.html>