I think the hyphen question is settled – we can go with hv_type and vm_mode to 
be in line with the rest of nova.

Now for the other bit…

After this email thread and discussion in the IRC with those who expressed 
interest I have come to the following:

I will use the name supported_hv_specs instead of supported_instances in the 
ComputeNode object and HVSpec for the new object. So the field type of 
supported_hv_specs will be ListOfObjectsField(‘HVSpec’).

The supported_instances field in the compute_nodes table will be left as it is. 
This means that supported_hv_specs in ComputeNodes will map to the 
supported_instances field in the compute_nodes table.

Thanks for helping,

From: Paul Murray [mailto:ptma...@gmail.com]
Sent: 10 October 2014 13:00
To: Murray, Paul (HP Cloud)
Subject: Fwd: [openstack-dev] [Nova] object field naming question

---------- Forwarded message ----------
From: Dan Smith <d...@danplanet.com<mailto:d...@danplanet.com>>
Date: 9 October 2014 17:40
Subject: Re: [openstack-dev] [Nova] object field naming question
To: "OpenStack Development Mailing List (not for usage questions)" 

> The value it adds (and that an underscore would add in hvtype ->
> hv_type) is that the name would match the naming style for the vast
> majority of everything else in OpenStack. See, for examples:


> As mentioned in the review, I disagree on this point, since "doing a
> cleanup afterwards" would mean having to increment the
> nova.objects.SupportedInstance model VERSION as soon as it went into
> master. I say let's make the quick change now and avoid having to write
> code like this in the next patchset:
>  if client_version <= (1,0):
>     # We renamed hvtype to hv_type in 1.1
>     self.hv_type = fields.get('hvtype')

Right, this becomes RPC debt if we think we might change it later. We
definitely want to get it right the first time whenever possible.


OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to