On Fri, 2019-01-25 at 16:35 +0000, Stephen Finucane wrote:
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. you can get the hashed host-id form the instance metadata to determin if two instance are on the same host from a tenant perspective in a hypervior indepent way so i think that usecase would still be supported.
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