[openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

Sylvain Bauza sbauza at redhat.com
Thu Sep 4 16:13:06 UTC 2014


Le 04/09/2014 17:57, Daniel P. Berrange a écrit :
> On Thu, Sep 04, 2014 at 03:49:26PM +0000, Dugger, Donald D wrote:
>> Actually, I think Sylvain's point is even stronger as I don't think
>> splitting the virt drivers out of Nova is a complete fix.  It may
>> solve the review latency for the virt driver area but, unless virt
>> drivers are the bulk of Nova patches, the Nova core team will still
>> be swamped with review requests.  Some solution, maybe half-cores,
>> will still be needed for Nova long term.
> Absolutely, nova core will still have an awful lot of work todo
> and will need to have fresh blood. The split will free up some %
> of existing cores time though as there's certainly plenty of virt
> driver only patches going through merge that are taking up non
> negligble review time. eg I've done loads of review on vmware
> only code which I'd be relieved of with vmware maintainers able
> to form their own review core for their driver. There is also the
> fact that people are holding back on even submitting code for
> many drivers because they know it'll never get reviewed. So the
> proportion of virt driver only code is likely to be higher than
> what we currently see on review today.
>

I totally understand your point and I agree with it. I'm just thinking 
that for Kilo and Lxxx, we also need to experiment some halfcore teams 
in order to free up your review duty, at least until the virt code is 
splitted out correctly.

On a side note, assuming I'm a non-core (so you can just throw my 
advice), I don't think the runway/slot proposal for Kilo will increase 
the reviewing bandwidth as it will just create another layer of 
prioritization without addressing the velocity. In another world, that's 
not because you just create a Scrum's sprint with 2 people and provide 
poker planning that you can address a 2-month man-day work.

-Sylvain

> Regards,
> Daniel




More information about the OpenStack-dev mailing list