Open Stack

On 02/24/2015 03:21 PM, Joe Gordon wrote:
> 
> 
> On Tue, Feb 24, 2015 at 6:57 AM, Daniel P. Berrange <berrange at redhat.com
> <mailto:berrange at redhat.com>> wrote:
> 
>     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.
> 
> 
> I tend to agree with you on this.  I don't think completing the
> refactoring of the horizontal efforts is a pre-requisite of adjusting
> the release model for projects that will be having a coordinated release
> for the foreseeable future.  That being said, maybe it would be easier
> to pick off the projects that don't need to be part of a coordinated
> release first.

Definitely. And doing so would produce a lot of lessons learned about
what's needed to do this correctly. I expect that we can actually free a
lot of projects to do that in Liberty cycle, get some feedback on how
that's working, and evaluate what we can peel off in Marmite.

	-Sean

-- 
Sean Dague
http://dague.net