Open Stack

On Tue, Feb 24, 2015 at 6:57 AM, Daniel P. Berrange <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.

The way to  discuss a concrete proposal and consider using it is to push a
patch up to the governance repo.


>
> 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
> :|
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150224/7ffdd93f/attachment-0001.html>