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 

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 

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.

OpenStack-dev mailing list

Reply via email to