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

Nikola Đipanov ndipanov at redhat.com
Fri Sep 5 10:52:29 UTC 2014


On 09/05/2014 01:26 AM, Jay Pipes wrote:
> On 09/04/2014 10:33 AM, Dugger, Donald D wrote:
>> Basically +1 with what Daniel is saying (note that, as mentioned, a
>> side effect of our effort to split out the scheduler will help but
>> not solve this problem).
> 
> The difference between Dan's proposal and the Gantt split is that Dan's
> proposal features quite prominently the following:
> 
> == begin ==
> 
>  - The nova/virt/driver.py class would need to be much better
>    specified. All parameters / return values which are opaque dicts
>    must be replaced with objects + attributes. Completion of the
>    objectification work is mandatory, so there is cleaner separation
>    between virt driver impls & the rest of Nova.
> 
> == end ==
> 
> In other words, Dan's proposal above is EXACTLY what I've been saying
> needs to be done to the interfaces between nova-conductor, nova-compute,
> and nova-scheduler *before* any split of the scheduler code is even
> remotely feasible.
> 
> Splitting the scheduler out before this is done would actually not "help
> but not solve this problem" -- it would instead further the problem, IMO.
> 

I don't think it's news to anyone that I strongly agree with the above
but let me restate that once more:

+1000

Not only that - but we need to make sure the APIs are *good and sane*
too. This is where the real meat of these types of problems is really.

If you need an example of why this is so crazy important - take a look
at Cinder that did get split out, and all the grief that came from it
the API being half baked ([1], [2], but there is plenty more examples).

Actually - as I write this I think of Ironic and can't help but think
that the API is _so freakin' important_ that you actually might be
better off writing the whole thing from scratch just to get the API right.

[1] https://review.openstack.org/#/c/87546/
[2] https://bugs.launchpad.net/tempest/+bug/1302774

N.



More information about the OpenStack-dev mailing list