[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