[openstack-dev] [nova] RT/Scheduler summit summary and Kilo development plan

Daniel P. Berrange berrange at redhat.com
Mon Nov 17 16:07:52 UTC 2014

On Mon, Nov 17, 2014 at 10:58:52AM -0500, Jay Pipes wrote:
> Good morning Stackers,
> At the summit in Paris, we put together a plan for work on the Nova resource
> tracker and scheduler in the Kilo timeframe. A large number of contributors
> across many companies are all working on this particular part of the Nova
> code base, so it's important that we keep coordinated and updated on the
> overall efforts. I'll work together with Don Dugger this cycle to make sure
> we make steady, measured progress. If you are involved in this effort,
> please do be sure to attend the weekly scheduler IRC meetings [1] (Tuesdays
> @ 1500UTC on #openstack-meeting).
> == Decisions from Summit ==
> The following decisions were made at the summit session [2]:
> 1) The patch series for virt CPU pinning [3] and huge page support [4] shall
> not be approved until nova/virt/hardware.py is modified to use nova.objects
> as its serialization/domain object model. Jay is responsible for the
> conversion patches, and this patch series should be fully proposed by end of
> this week.
> 2) We agreed on the concepts introduced by the resource-objects blueprint
> [5], with a caveat that child object versioning be discussed in greater
> depth with Jay, Paul, and Dan Smith.
> 3) We agreed on all concepts and implementation from the 2
> isolate-scheduler-db blueprints: aggregates [6] and instance groups [7]
> 4) We agreed on implementation and need for separating compute node object
> from the service object [8]
> 5) We agreed on concept and implementation for converting the request spec
> from a dict to a versioned object [9] as well as converting
> select_destinations() to use said object [10]
> [6] We agreed on the need for returning a proper object from the virt
> driver's get_available_resource() method [11] but AFAICR, we did not say
> that this object needed to use nova/objects because this is an interface
> internal to the virt layer and resource tracker, and the ComputeNode
> nova.object will handle the setting of resource-related fields properly.

IIRC the consensus was that people didn't see the point in the
get_available_resource using a different objects compared to the
Nova object for the stuff used by the RT / scheduler. To that end
I wrote a spec up that describes an idea for just using a single
set of nova objects end-to-end.


Presumably this would have to dovetail with your resource object
models spec.


Perhaps we should consider your spec as the place where we define
what all the objects look like, and have my blueprint just focus
on the actual conversion of get_available_resource() method impls
in the virt drivers ?

|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

More information about the OpenStack-dev mailing list