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