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

Sylvain Bauza sbauza at redhat.com
Fri Sep 5 06:59:03 UTC 2014


Le 05/09/2014 01:26, Jay Pipes a écrit :
> 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.
>

Jay, we agreed on a plan to carry on, please be sure we're working on 
it, see the Gantt meetings logs for what my vision is.


That said, I think this concern of clean interfaces also applies to this 
thread: if we want to spin off the virt drivers out of Nova git repo, 
that does requires a cleanup on the interfaces, in particular on the 
compute manager and the resource tracker, where a lot of bits are still 
strongly tied and not versionified (thanks to JSON dicts).

So, this effort requires at least one cycle, and as Dan stated, there is 
urgency, so I think we need to identify a short-term solution which 
doesn't require refactoring. My personal opinion is what Russell and 
Thierry expressed, ie. subteam delegation (to what I call "half-cores") 
for iterations and only approvals for cores.

-Sylvain


> Best,
> -jay
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list