[nova] Per-instance serial number implementation question

Sean Mooney smooney at redhat.com
Fri Jan 25 16:47:46 UTC 2019

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
> [1] https://libvirt.org/formatdomain.html#elementsSysinfo

More information about the openstack-discuss mailing list