Open Stack

On Tue, Feb 24, 2015 at 08:50:45AM -0500, Sean Dague wrote:
> 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.

I pretty much fully agree that refactoring the horizontal efforts to
distribute responsbility across the individual projects is the way
forward. I don't think it needs to be a pre-requisite step for changing
the release cycle. We can do both in parallel if we put our minds to
it.

My biggest fear is that we just keeping debating problems and alternatives,
but continue to be too afraid of theoretical problems, to actually take the
risk of effecting meaningful improvemnts in the operation of the project.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|