[nova] Per-instance serial number implementation question

Stephen Finucane sfinucan at redhat.com
Fri Jan 25 15:03:47 UTC 2019


On Thu, 2019-01-24 at 09:09 -0600, Matt Riedemann wrote:
> The proposal from the spec for this feature was to add an image property 
> (hw_unique_serial), flavor extra spec (hw:unique_serial) and new 
> "unique" choice to the [libvirt]/sysinfo_serial config option. The image 
> property and extra spec would be booleans but really only True values 
> make sense and False would be more or less ignored. There were no plans 
> to enforce strict checking of a boolean value, e.g. if the image 
> property was True but the flavor extra spec was False, we would not 
> raise an exception for incompatible values, we would just use OR logic 
> and take the image property True value.
> 
> The boolean usage proposed is a bit confusing, as can be seen from 
> comments in the spec [1] and the proposed code change [2].
> 
> After thinking about this a bit, I'm now thinking maybe we should just 
> use a single-value enum for the image property and flavor extra spec:
> 
> image: hw_guest_serial=unique
> flavor: hw:guest_serial=unique
> 
> If either are set, then we use a unique serial number for the guest. If 
> neither are set, then the serial number is based on the host 
> configuration as it is today.
> 
> I think that's more clear usage, do others agree? Alex does. I can't 
> think of any cases where users would want hw_unique_serial=False, so 
> this removes that ability and confusion over whether or not to enforce 
> mismatching booleans.

Makes sense - we do that for 'hw_cpu_policy', for example (we have
'dedicated' and 'shared', but they're essentially booleans). However,
the reason we added 'hw:cpu_policy=shared' (the flavor extra spec) was
to provide a way for operators to prevent users requesting pinned CPUs
via images metadata if they didn't want them in their cloud. At the
risk of rehasing what's in the spec, if there aren't cases where users
would want 'hw_unique_serial=False' then what is the upside of ever
supporting non-unique serials going forward? Could we not just default
to unique serials, avoiding these knobs? 


Stephen

> [1] https://review.openstack.org/#/c/612531/2/specs/stein/approved/per-instance-libvirt-sysinfo-serial.rst@43
> [2] https://review.openstack.org/#/c/619953/7/nova/virt/libvirt/driver.py@4894





More information about the openstack-discuss mailing list