Open Stack

On Fri, 2019-01-25 at 10:09 -0600, Matt Riedemann wrote:
> On 1/25/2019 9:03 AM, Stephen Finucane wrote:
> > 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?
> 
> The answer to this, and Jay's same question elsewhere in this thread, is 
> likely going to need to come from danpb who I think originally added the 
> serial stuff in the libvirt driver. I could not find discussions about 
> why the serial was per-host rather than per-guest in the original code 
> changes. So besides "this is the way it's always been" and I'm risk 
> averse to backward incompatible changes, I don't have a good answer.

Chatted with Dan about this. In summary, this value is up to apps (i.e.
nova) to populate. That said, as noted in the spec, nova currently
populates this using the value of the host OS' '/etc/machine-id' file.
It is possible that operators/users are using this to determine if two
guests are co-located. He noted that one would be a valid point in
claiming the host OS identity should have been reported in
'chassis.serial' instead of 'system.serial' in the first place [1] but
changing it now is definitely not zero risk.

My personal take on that is that we can avoid the configurable option
and it might be good to start reporting 'chassis.serial' in case anyone
was doing the above (assuming we care about that possible use case).
We'd just need to make sure the change in behaviour was fully
documented by way of an 'upgrade' reno. That's just my take though.

Stephen

[1] https://libvirt.org/formatdomain.html#elementsSysinfo