Re: [PATCH] qemucapabilitiestest: Bump qemu-5.1 capabilities for x86_64
On Wed, Jun 03, 2020 at 11:45:49 +0200, Peter Krempa wrote:
On Wed, Jun 03, 2020 at 11:37:21 +0200, Erik Skultety wrote:
> 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:
[...]
> > 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?
I don't think that's a particularly worthwhile idea. It would have to
run fully emulated to shield from cpu differences which would make it
super slow. In such case I'll rather periodically or on request update
it myself rather than deal with something which takes ages.
Also the problem of having a stable way to generate capabilities is
orthogonal to the original problem of whether to review the capabilities
or not.
I still think manual review is necessary regardless of how stable the
way to generate the capabilities is and in some cases there are even
differences which break tests (recent dropping of the 0.13 machine type
from upstream qemu, deprecation of some commands etc.) so I don't see
a way how this part can be avoided or any reasonably simple set of rules
for avoiding review to be established.
Obviously having a stable way to create capabilities would be certainly
desirable for other scenarios, but not at the cost of running it in TCG.
If we want to achieve that we probably will need a way to strip cpu
related commands from the capabilities and leave cpu probing for a
different test.
This in the end may be desirable due to other reasons as well, but I'm
certainly not sure how to achieve that. As of such I'll gladly continue
updating the capabilities on request by others for now as it doesn't
really cause any burden for me and I need to update it anyways for stuff
I'm developing.