Open Stack

Hi All,

The following question relates to this change:

https://review.openstack.org/#/c/125091/

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 supported_instances.

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).

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.

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)?

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

Thanks,
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141009/cf350af5/attachment.html>