On 02/24/2015 03:21 PM, Joe Gordon wrote:
>
>
> On Tue, Feb 24, 2015 at 6:57 AM, Daniel P. Berrange <berra...@redhat.com
> <mailto:berra...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
