tl;dr:  we're not broken, but under stress...changing (outside)
expectations requires changing the expression of the model...while it's
called a 'stack' maybe it's multiple tiered stacks.  MultiStack!

On Mon, Sep 22, 2014 at 4:27 PM, Doug Hellmann <>

> The point of integration is to add the projects to the integrated
> *release*, not just the gate, because the release is the thing we have said
> is OpenStack. Integration was about our overall project identity and
> governance. The testing was a requirement to be accepted, not a goal.
> If there is no incubation process, and only a fixed list of projects will
> be in that new layer 1 group, then do contributors to the other projects
> have ATC status and vote for the TC? What is the basis for the TC accepting
> any responsibility for the project, and for the project agreeing to the
> TC’s leadership?

This is one reason for multiple layers.  The original 4 layer stack was
meant as a technical dependency stack but has morphed into a social/project
organizational stack.  I don't think it is total coincidence that the
technical hierarchy was interpreted as a social/governance hierarchy by
some as there is a lot of similarity.  The mapping between the two in my
mind is fairly easy, but those details is not what is important.

We love to look at the Apache Foundation for inspiration.  In the current
set of Apache projects most of them are not focused on adding value to a
web server.  They grew beyond that in multiple directions.

I'm selfish and want to keep the layer nomenclature for the technical
organization that helped re-structure DevStack and propose we think of
these as *thing*[0] where we have Multiple *Things*:

* IaaS thing: the stuff that builds excellent clouds
* PaaS thing: the stuff that does amazing things that may or may not be
built on top of excellent clouds
* XaaS thing(s): more things I can not visualize through the fog of
* Non-aas developer things: what enables us s developers to make the above
things (infra, qa, etc)
* Non-aas consumer[1] things: what enables the rest of the world to enjoy
the above things (docs, SDKs, clients, etc)

This separates the technical hierarchical from the organizational
relationships.  All of the above things are still called OpenStack.  But
maybe it's a 'MultiStack'.

- New projects wanting to join can apply and receive a 'provisional'
attribute that tells the world we (OpenStack people) thing this looks
promising and want to see if it matures to our standards.  Similar to
incubation but maybe the bar has some differences between the things.  It
_should_ require a higher bar to add to the foundation than a new deck on
the side.

- The integrated release still applies to a subset of the projects and/or
things.  The IaaS thing establishes the base release cycle other things
apply common sense and follow along or release more often.

- The test matrix is built using the technical layers and not the above
organizational structure.  I'm getting a bit hand-wavy here, but the point
is to clearly state to the world that it isn't the organizational things
that determine testing beyond having at least the 'provisional' attribute
on a project.

If the above feels very familiar it should.  Some of it is terminology
changes to help change expectations and some divisions based on use cases.
What we have isn't totally broken, it is under growth related stress.
Taking a different perspective on it will help expose where things can be
improved.  And what we are doing right.


[0] TODO: cut-n-paste in actual allegorical noun
[1] Yuck, better word here too!


Dean Troyer
OpenStack-dev mailing list

Reply via email to