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.
