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  (Tuesdays > @ 1500UTC on #openstack-meeting). > > == Decisions from Summit == > > The following decisions were made at the summit session : > > 1) The patch series for virt CPU pinning  and huge page support  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 > , 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  and instance groups  > > 4) We agreed on implementation and need for separating compute node object > from the service object  > > 5) We agreed on concept and implementation for converting the request spec > from a dict to a versioned object  as well as converting > select_destinations() to use said object  > >  We agreed on the need for returning a proper object from the virt > driver's get_available_resource() method  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 OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev