[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