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

[Erik Skultety]

On Wed, Jun 03, 2020 at 11:29:36AM +0200, Peter Krempa wrote:
> On Wed, Jun 03, 2020 at 11:11:08 +0200, Michal Privoznik wrote:
> > 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
>
> I certainly am doing that when generating files after the release to
> ensure that we don't regress in anything. Obviously only on the level of
> detected capabilities.
>
> > 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?
>
> Well. They are built on fedora, but certainly not taken from fedora.
> It's built from git.
>
> > Maybe we can document configure arguments for QEMU so that it is
> > reproducible.
>
> While I agree that we should do that to take one of the moving parts out
> of the equation we still can't do anything about the machine dependance
> of the output. Specifically it contains all cpu flags so it really can't
> be re-generated reproducibly on a box with even a slightly different
> cpu.
>
> Ideally we'd build it with the fedora spec-file, but I got lazy and I'm
> usually just re-running configure from my history in this case.
>
> My only idea how to provide stable output is to create a job on a box
> which will periodically re-build qemu and fetch the capabilities and
> publish them somewhere so that others could grab those and refresh the
> caps themselves, but I can't really think of a way how to enable others
> do it on their machine whithout messing up the CPU.

You beat me in the response time wrt reply :). Hmm, how about we add this as a
job to lcitool which controls how virt-install is spawned, that way + an Ansible
playbook you always get a reproducible environment?

Erik