[PATCH] qemucapabilitiestest: Bump qemu-5.1 capabilities for x86_64
Michal Privoznik
mprivozn at redhat.com
Wed Jun 3 09:11:08 UTC 2020
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 at redhat.com>
>>> ---
>>> 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 at redhat.com>
>>
>> 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.
Michal
More information about the libvir-list
mailing list