Open Stack

I spent a little time trying to work out a good way to include this kind of data in the ComputeNode object. You will have seen that I added the supported_instances reported to the RT by the virt drivers as a list of HVSpec – where HVSpec is a new nova object I created for the purpose.

>> The rationale behind two parallel data model hiercharies is that the
>> format the virt drivers report data in, is not likely to be exactly
>> the same as the format that the resoure tracker / scheduler wishes to
>> use in the database.

>Yeah, and in cases where we know where that line is, it makes sense to
>use the lighter-weight modeling for sure.

Something that happens in some cases in RT is the data reported by the virt driver is modified by the RT – this is certainly the case for stats (which should probably not have been used by the virt driver – ironic in this case). In other cases memory, cpu, disk etc are split out into other fields at the moment (which is where Jay Pipes is working on a model for resources in general).

Where the data in an object field is not simple (e.g. lists of something) it is not really easy to work with in an object. You can’t just add to a list that is already stored in an object field, you need to make sure the object knows it has been updated. So the easiest way to work is to add entire fields to the object and not change them in situ. So that seems to me like dealing with non-nova object data types makes sense as something separate to, say, the ComputeNode object.

An alternative would be to work on the way nova object handle nested data structures (i.e. recognizing updates in nested structures, api allowing for list manipulation etc.) It depends whether you think the objects are just doing versioning to support upgrade/mixed versions or are a general purpose object model.

Note that this happens with NUMA data structures and PCI as well at the moment.

>> FWIW, my patch series is logically split up into two parts. THe first
>> 10 or so patches are just thought of as general cleanup and useful to
>> Nova regardless of what we decide todo. The second 10 or so patches
>> are where the objects start appearing & getting used & the controversial
>> bits needing mor detailed discussion.

>Right, so after some discussion I think we should go ahead and merge the
>bottom of this set (all of them are now acked I think) and continue the
>discussion on the top half where the modeling is introduced.


Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141022/bcb0337f/attachment.html>