On Mon, Sep 15, 2014 at 11:00:15AM +0200, Thierry Carrez wrote: > Chris Friesen wrote: > > On 09/12/2014 04:59 PM, Joe Gordon wrote: > >> [...] > >> Can't you replace the word 'libvirt code' with 'nova code' and this > >> would still be true? Do you think landing virt driver code is harder > >> then landing non virt driver code? If so do you have any numbers to back > >> this up? > >> > >> If the issue here is 'landing code in nova is too painful', then we > >> should discuss solving that more generalized issue first, and maybe we > >> conclude that pulling out the virt drivers gets us the most bang for our > >> buck. But unless we have that more general discussion, saying the right > >> fix for that is to spend a large amount of time working specifically on > >> virt driver related issues seems premature. > > > > I agree that this is a nova issue in general, though I suspect that the > > virt drivers have quite separate developer communities so maybe they > > feel the pain more clearly. But I think the solution is the same in > > both cases: > > > > 1) Allow people to be responsible for a subset of the nova code > > (scheduler, virt, conductor, compute, or even just a single driver). > > They would have significant responsibility for that area of the code. > > This would serve several purposes--people with deep domain-specific > > knowledge would be able to review code that touches that domain, and it > > would free up the nova core team to look at the higher-level picture. > > For changes that cross domains, the people from the relevant domains > > would need to be involved. > > > > 2) Modify the gate tests such that changes that are wholly contained > > within a single area of code are not blocked by gate-blocking-bugs in > > unrelated areas of the code. > > I agree... Landing code in Nova is generally too painful, but the pain > is most apparent in areas which require specific domain expertise (like > a virt driver, where not so many -core are familiar enough with the > domain to review, while the code proposer generally is).
Yes, all of Nova is suffering from the pain of merge. I am specifically attacking only the virt drivers in my proposal because I think that has the greatest liklihood of making a noticable improvement to the project. Their teams are already fairly separated from the rest of nova because of the domain expertize, and the code is also probably the most well isolated and logically makes sense as a plugin architecture. We'd be hard pressed to split of other chunks of Nova beyond the schedular that we're already talking about. > IMHO, like I said before, the solution to making Nova (or any other > project, actually) more fluid is to create separate and smaller areas of > expertise, and allow new people to step up and own things. Splitting > virt drivers (once the driver interface is cleaned up) is just one way > of doing it -- that just seems like a natural separation line to use if > we do split. But that would just be a first step: as more internal > interfaces are cleaned up we could (and should) split more. Smaller > groups responsible for smaller areas of code is the way to go. And history of OpenStack projects splitting off shows this can be very successful too 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
