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@xxxxxxxxxx> > > > > > --- > > > > > 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@xxxxxxxxxx> > > > > > > > > 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
