On 10/09/2014 09:45 AM, Murray, Paul (HP Cloud) wrote:
Hi All,

The following question relates to this change:


This change adds a field to the ComputeNode object called
“supported_instances”. It also adds an object called “SupportedInstance”
that has fields called “arch”, “hvtype” and “vm_mode”.

All these names already exist in the nova code, but when put together in
these objects they seem a little odd (i.e. supported_instances may be a
little misleading, hvtype has no hyphen but vm_mode does). This is where
they come from:

-supported_instances is the name of the corresponding field of the
compute_nodes database table. The supported_instances field actually
contains a the list of architecture, hypervisor type and vm_mode
combinations supported by the compute node. It is also the existing
field name used in a dict provided by the virt drivers to report this
list to nova.

-arch, hvtype and vm_mode are the names used by variables throughout
nova that refer to the relevant data obtained contained in

The question is: are these the names we actually want to use?

The reason I ask is that once the names are used for Nova object fields,
the nova object versions would need to be bumped to change them. So if
they are going to change, now would be a good time to put the right
thing in the objects (the rest of nova could be changed subsequently).

Right, exactly.

So, do you think supported_instances should be something else, e.g.
supported_hv_properties? (The SupportedInstance object name can follow
this one.) Please make a suggestion if you think it should change.

Yeah, supported_hv_properties works for me. ++

Do you think we should have hyphens or not in hvtype and vm_mode (note,
vm_mode occurs 160+ times in nova and vmmode occurs 12 times, whereas
occurrence of hv_type vs hvtype has the opposite bias).

In fact, is there a convention that should be followed that I have
forgotten about (or never knew)?

The convention throughout OpenStack code is to use underscore separation. Not having underscore separation is the exception, not the rule.


Let me know opinions and I will fix the patch accordingly.



OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to