[openstack-dev] [Nova] structure of supported_instances field (architecture, hypervisor type, vm mode) ?

Jay Pipes jaypipes at gmail.com
Fri Oct 3 15:45:07 UTC 2014



On 10/03/2014 11:29 AM, Daniel P. Berrange wrote:
> On Fri, Oct 03, 2014 at 03:16:02PM +0000, Murray, Paul (HP Cloud) wrote:
>> Hi All,
>>
>> I have a question about information used to determine if a host supports an image.
>>
>> The virt drivers all provide a list of triples of the form (architecture,
>> hypervisor type, vm mode). Each triple is compared to the corresponding three
>> image properties in a request in the scheduler filter called image_props_filter.py
>> to determine if a host can support the given image. This information is held in a
>> field in the compute_nodes table called supported_instances.
>>
>> I am adding the supported_instances field to the ComputeNode object. As it has a
>> definite structure I want to make sure the structure is checked.
>>
>> So here is my question:
>>
>> Am I right in thinking that there are always three properties in each element
>> in the list (architecture, hypervisor type, vm mode)?
>>
>> As far as I can tell, these are the only values checked in the filter and all
>> the virt drivers always generate those three. If so, is it reasonable for me
>> to insist the elements of the supported_instance list have three strings in
>> them when the object checks the data type? I don't want to restrict the
>> structure to being strictly a list of triples if there might in fact be a
>> variable number of properties provided.
>
> Yes, there should always be exactly 3 elements in the list and they should
> all have non-NULL values. Valid values are defined as constants in the
> nova.compute.{arch,hvtype,vm_mode}. So any deviation from this is considered
> to be a bug.
>
> FYI I'm currently working on changing the get_available_resources() method
> to return a formal object, instead of its horrible undocumented dict().
> With this, the current list of lists / JSON used for supported_instances
> will turn into a formal object with strict validation.

yay!

-jay



More information about the OpenStack-dev mailing list