Comment 57 for bug 1887490
Revision history for this message
| Christian Ehrhardt (paelzer) wrote | #57 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
Arr, this is a bad case :-/
First of all - yes Sven it is a regression. Somewhat relieved by having a workaround, but not making it not a regression.
First of all I have to beg all your pardon for not seeing this earlier, due to the bug tasks being closed most of the review passed that we have on recent and/or dormant bugs filter them out. And now sadly it feels "too late" to make it much better.
The underlying problem in this case is that the resolution seems to make it only worse.
Let me explain that...
If we'd take away the new features in the package itself, then anything started with 6.0.0-0ubuntu8.5 and later would conflict with the new update. And that means we are comparing two sets of guests - those started in the first 11 months vs those started (or restarted) in the last 14 months. Even purely on numbers that quite likely means the latter group would win.
Furthermore - unless I'm mistaken - all future versions Groovy, Hirsute, Impish, Jammy, ... match upstream which has the features added on those types. Due to that reverting this we'd also make Focals types incompatible with future releases and inhibit migration and similar to those.
In the meantime (between now and the introduction of this change to the type) there were also two qemu security updates [1][2] which usually imply to restart or migrate the guests. So quite likely the majority of those left started before 03/2021 have been re-cycled since then.
I do not think that versioned types would help here (but haven't spent days to experiment with it), at least not for those guests already running from the past - and those are the only ones left affected.
So what else than shrugging and feeling bad could we do ...?
I think we could as lessons learned harden the regression tests a bit better.
We could:
1. ensure that no cpu-model is lost only new, but no lost entries in $ virsh cpu-models $(uname -m)
2. ensure that we only got adds, but no removals in /usr/share/
Those will be helpful, but were not the problem here (we only got Rome added, no change to EPYC named types), the problem is that there are now "known features" which before was just noise in the cpuid data. Now that it is detected properly
3. (Src) check if tests/cputestdata or tests/domaincap
I've added that to the list of known "should be tested better on regression checks" so that it can be implemented to catch those cases earlier next time.
[1]: https:/
[2]: https:/
Ref: SD-670