Open Stack

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.

  https://review.openstack.org/#/c/133728/

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

  https://review.openstack.org/#/c/127609/

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 ?

Regards,
Daniel
-- 
|: 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 :|