Le 03/10/2014 17:29, Daniel P. Berrange a écrit :
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.
Oh thanks Daniel for that effort, it will ease a lot the scheduler split
because we want to change into objects all the updates to the Scheduler
or the request_data dict when asking for selecting a destination.
Thanks,
-Sylvain
Regards,
Daniel
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
