Open Stack

On Thu, 2019-01-31 at 19:31 +0800, Zhenyu Zheng wrote:
> Thanks alot for bring this up, if we decided to make unique serial
> the only choice, I guess we have to sort on what curcumstances it
> willchange the serial of instances that already exists. Should we
> have a way to preserve the serial for exisiting instances in order to
> not
> cause any workload failue for our customers as changing the serial
> may cause some problem.

I think all that's necessary here is to add a reno calling out this
change in behavior (along with the alternatives put forth by Sean and
Matt) and, ideally, start setting 'chassis.serial' if libvirt > 4.1.0?

Stephen

> On Sat, Jan 26, 2019 at 7:30 PM Stephen Finucane <sfinucan at redhat.com
> > wrote:
> > On Fri, 2019-01-25 at 18:52 -0600, Matt Riedemann wrote:
> > 
> > > On 1/25/2019 10:35 AM, Stephen Finucane wrote:
> > 
> > > > 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.
> > 
> > > 
> > 
> > > If I'm reading those docs correctly, chassis.serial was new in
> > libvirt 
> > 
> > > 4.1.0 which is quite a bit newer than our minimum libvirt version
> > support.
> > 
> > 
> > 
> > Good point. Guess it doesn't matter though if we have the two
> > 
> > alternatives you and Sean have suggested for figuring this stuff
> > out?
> > 
> > The important thing is that release note. Setting 'chassis.serial'
> > 
> > would be a nice TODO if we have 4.1.0.
> > 
> > 
> > 
> > Stephen
> > 
> > 
> > 
> > 
> > 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190131/8bd1336f/attachment.html>