Open Stack

On 02/24/2015 07:48 AM, Russell Bryant wrote:
> On 02/24/2015 12:54 PM, Daniel P. Berrange wrote:
>> On Tue, Feb 24, 2015 at 11:48:29AM +0000, Chris Dent wrote:
>>> On Tue, 24 Feb 2015, Daniel P. Berrange wrote:
>>>
>>>> need to do more work. If this is so, then I don't think this is a blocker,
>>>> it is just a sign that the project needs to focus on providing more resources
>>>> to the teams impacted in that way.
>>>
>>> What are the mechanisms whereby the project provides more resources
>>> to teams?
>>
>> The technical committee and / or foundation board can highlight the need
>> for investment of resources in critical areas of the project, to either
>> the community members or vendors involved. As an example, this was done
>> successfully recently to increase involvement in maintaining the EC2
>> API support.  There are plenty of vendors involved in OpenStack which
>> have the ability to target resources, if they can learn where those
>> resources are best spent.
> 
> Indeed ... and if horizontal teams are the ones hit the most by the
> extra work, each project should help with that burden.  For example,
> projects may need to take their responsibility for documentation more
> seriously and require documentation with features (content at least, not
> necessarily integration into the proper documentation deliverables)
> instead of assuming it magically gets written later.

Right, and I think this actually hits at the most important part of the
discussion. The question of:

1) what would we need to do to make different release cadences viable?
2) are those good things to do regardless of release cadence?

The horizontal teams really can't function at different cadences. It
completely breaks any flow and planning at turns them even further into
firefighting because now everyone has crunch time at different times,
and the horizontal efforts are required to just play catch up. I know
what that future looks like, the horizontal teams dry up because no one
wants that job.

Ok, so that being said, what we'd need to do is have horizontal teams
move to more of a self supporting model. So that the relevant content
for a project (docs, full stack tests, requirements, etc) all live
within that project itself, and aren't centrally synchronized.
Installation of projects needs to be fully isolated from each other so
that upgrading project A can be done independent of project B, as their
release cadences might all bit disparate. Basically, ever OpenStack
project needs to reabsorb the cross project efforts they've externalized.

Then if project A decided to move off the coupled release, it's impact
to the rest would be minimal. These are robust components that stand on
their own, and work well with robust other components.

Which... is basically the point of the big tent / new project governance
model. Decompose OpenStack from a giant blob of goo into Robust elements
that are more loosely coupled (so independently robust, and robust in
their interaction with others). Move the horizontal teams into
infrastructure vs. content roles, have projects own more of this content
themselves.

But it is a long hard process. Devstack external plugins was implement
to support this kind of model, but having walked a bunch of different
teams through this (at all skill levels) there ends up being a lot of
work to get this right, and a lot of rethinking by teams that assumed
their interaction with full stack testing is something they'd get to
contribute once and have someone else maintain (instead of something
they now need dedicated watchful eye on).

The amount of full stack configurations immediately goes beyond anywhere
near testable, so it requires more robust project testing to ensure
every exposed interface is more robust (i.e. the testing in pyramids
from https://review.openstack.org/#/c/150653/).

And, I think the answer to #2 is: yes, this just makes it all better.

So, honestly, I'm massively supportive of the end game. I've been
carving out the bits of this I can for the last six months. But I think
the way we get there is to actually get the refactoring of the
horizontal efforts first.

That also provides a very concrete answer to "will people show up".
Because if they do, and we get this horizontal refactoring happening,
then we get to the point of being able to change release cadences
faster. If they don't, we remain with the existing system. Vs changing
the system and hoping someone is going to run in and backfill the breaks.

	-Sean

-- 
Sean Dague
http://dague.net