Open Stack

On Thu, 2019-01-31 at 11:55 +0000, Stephen Finucane wrote:
> 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 will
> > change 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?
since the workloads would already have to tolerate the serial changingn after a migration anyway
i think we should be fine with jsut the reno as stephen says.

> 
> 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
> > > 
> > > 
> 
>