On Thu, Sep 04, 2014 at 03:54:28PM -0700, Stefano Maffulli wrote: > Thanks Daniel for taking the time to write such deep message. Obviously > you have thought about this issue for a long time and your opinion comes > from deep personal understanding. I'm adding tags for neutron and > cinder, as I know they're having similar conversations. > > I don't have a strong opinion on the solution you and Kyle seem to be > leaning toward, I just have a couple of comments/warnings below > > On 09/04/2014 03:24 AM, Daniel P. Berrange wrote: > > saying 'This Is a Large Crisis'. A large crisis requires a large > > plan. > > Not necessarily, quite the contrary indeed. To address and solve big > problems, experience and management literature suggest it's a lot better > to make *one* small change, measure its effect and make one more change, > measure its effect, and on and on until perfection. The discussion > triggered by TripleO about 'what to measure' goes in the right > direction.[1]
FWIW, don't read too much into that particular paragraph/sentance - it is a humourous joke/quote from a british TV comedy :-) > Your proposal seem to require a long term investment before its effects > can be visible, although some of the things necessary for the split will > be needed anyway. Do you think there are small changes with high impact > that we can refine in Paris and put in place for Juno? If we wanted to do a short term improvement, we'd probably have to look at relaxing the way we apply our current 2 x +2 == +A policy in some way. eg we'd have to look at perhaps identifying core virt driver team members, and then treating their +1s as equivalent to a +2 if given on a virt-driver only change, and so setting +A after only getting one +2. > The other comment I have is about the risks of splitting teams and > create new ones whose only expertise is their company's domain. I'm > concerned of the bad side effect of having teams in Nova Program with > very limited or no incentive at all to participate in nova-common > project since all they care about will be their little (proprietary) > hypervisor or network driver. I fear we may end up with nova-common > owned by a handful of people from a couple of companies, limping along, > while nova-drivers devs throw stones or ignore. > Maybe this worst case scenario of disenfranchised membership is not as > bad as I think it would be, I'm voicing my concern also to gauge this > risk better. What are your thoughts on this specific risk? How can we > mitigate it? One of the important things I think we need todo is firm up the nova internal virt driver API to make it more well specified, as a way to prevent some of the sloopy bad practice all the virt driers engage in today. I still see a fairly reasonable number of feature requests that will involve nova common code, so even with a virt driver split, the virt driver teams are forced to engage with the nova common code to get some non-trivial portion of their work done. So if virt driver teams don't help out with nova common code work, they're going to find life hard for themselves when they do have features that involve nova common. In many ways I think we are already suffering quite alot from the problem you describe today in several ways. A large portion of the people contributing to all the virt drivers only really focus their attention on their own area of interest, ignoring nova common. I cannot entirely blame them for that because learning more of nova is a significant investment of effort. This is one of the reasons we struggle to identify enough people with broad enough knowledge to promote to nova core. I think I can also see parallels in the relationship between the major projects (nova, neutron, cinder, etc) and the olso project. It is hard go get the downsteam consumer projects to take an active interest in work on oslo itself. This was probably worse when oslo first started out, but it is now a more established team. I accept that splitting the drivers out from nova common will probably re-inforce the separation of work to some degree. The biggest benefits will come to the virt driver teams themselves by unblocking them from all competing for the same finite core reviewer resource. The remaining nova core team will probably gain a little bit more time (perhaps 10-15%) by not having to pay attention to the virt driver code changes directly but overall it wouldn't be a drammatic improvement there. The overall reduction in repo size might help new contributors get up the on-ramp to being part of the team, since smaller codebases are easier to learn in general. Overall I don't have a knockout answer to your concern though, other than to say we're already facing that problem to quite a large extent and modularization as a general concept has proved quite successful for the growth of openstack projects that have split out from nova in the past. 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-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
