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 :| _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
