Re: [PATCH] qemucapabilitiestest: Bump qemu-5.1 capabilities for x86_64
On Wed, Jun 03, 2020 at 11:34:07 +0200, Erik Skultety wrote:
On Wed, Jun 03, 2020 at 11:11:08AM +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(a)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(a)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.
Not only that, we could set up an upstream fedora VM following those steps
(not just steps but the overall HW setup to unify the whole process) and
Are there any machines which are guaranteed to be stable? Machines which
are not in a cloud or something which can just be re-scheduled somewhere
else.
generating the capabilities whenever new qemu is tagged in git. Of
course,
We do this for pre-release versions too. IMO as the qemu dev cycle is
very long we want to periodically re-sync to allow developing features
in parallel and also be notified about deprecations which are detectable
via QMP introspection.
sometimes you need them earlier than an RC is tagged, but still, I
think it
would be beneficial to automate this process by setting up the agent in a way
it would send a patch/MR against libvirt.
Well. It's not worth doing too often though. I can't really quantify
when it's good enough to update. Specifically in some cases the bump
needs to happen as some new feature was added and you'd like to use it
so it definitely doesn't have a reasonable optimization function.
If it turns out this to be desirable from upstream libvirt POV, I can
set up
such an upstream runner.