Re: [PATCH] qemucapabilitiestest: Bump qemu-5.1 capabilities for x86_64

On 6/3/20 10:40 AM, Peter Krempa wrote: > On Wed, Jun 03, 2020 at 10:27:57 +0200, Michal Privoznik wrote: > > On 6/3/20 9:31 AM, Peter Krempa wrote: > > > QEMU added the machine types for the 5.1 release so let's update them. > > > > > > Other notable changes are 'cpu-throttle-tailslow' migration property, > > > 'zlib' compression for qcow2 images and absrtact socket support. > > > > > > Signed-off-by: Peter Krempa <pkrempa(a)redhat.com&gt; > > > --- > > > As usual, I'll be refreshing this until the release so that we always > > > have fresh capabilities to prevent any surprises with deprecation and > > > big updates. > > > > > > .../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 2 +- > > > .../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 2 +- > > > tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 2 +- > > > .../caps_5.1.0.x86_64.replies | 357 +++++++++++------- > > > .../caps_5.1.0.x86_64.xml | 14 +- > > > 5 files changed, 237 insertions(+), 140 deletions(-) > > > > Reviewed-by: Michal Privoznik <mprivozn(a)redhat.com&gt; > > > > Maybe we can have another rule that would allow you to push these without > > review? I can argue both ways, so I'm just putting it out there. > > Yeah. I thought about that too. > > Specifically one thing I'd like to avoid is carelessness in case of the > update. Specifically if there is some form of removal (flag being > removed and such) we need to be careful and consider the implications. Well, for that we would need to compare with older capabilities XML and I don't think we are doing that. Removal between the same capabilities XML of an unreleased QEMU are uncommon. But I hear what you're saying and that's my concern too. > > In this very specific case there's nothing of note and I'd be okay with > just pushing it, but the rules if we wanted to codify it somehow would > require to be more nuanced and I don't think I can express all the > caveats. > > That's why I didn't really argue for adding a special rule for this. > > Also one reason I'm doing periodic upgrades of this is so that others > don't have to do it. The problem here is that the output is very much > dependent on the machine where you run it and I don't want others to > have to update the files when adding a new capability as the difference > becomes unreviewable and may even regress depending on how qemu is > built. > This is a long known issue and perhaps it would be worth documenting somewhere? I think these are QEMU binaries taken from Fedora, is that so? Maybe we can document configure arguments for QEMU so that it is reproducible.