On Tue, Feb 24, 2015 at 6:57 AM, Daniel P. Berrange <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. 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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ 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