Re: [libvirt] [REPOST PATCH] tests: Update x86_64 replies, caps to QEMU 2.12

On 05/16/2018 11:09 AM, Pavel Hrdina wrote: But aren't some of the responses better tied to native hardware rather than virtualized (which I'm assuming a docker image may provide)? Especially the CPU ones and as seen from the s390x patch on list the response from qemuMonitorJSONGetKVMState. If we had/used the same, native box for each iteration of the capabilities files, then sure this probably would be easier unless someone (other than me ;-)) wants to mock a "fully featured" response. What we don't want to do is commit the emulated results, which I believe was done in the last go around - check the s390x results for the GetKVMState reply (libvirt-7) compared to what's posted upstream from real hardware yesterday by Shalini. I also don't think it's "right" to edit whatever CPU response one gets just because it's run on different hardware just so we can avoid polluting the diff. Again, back to my previous points - same, native hardware or better mocking... I was wondering why those xen* things showed up - perhaps because my environment included the xen-devel package... After removing, yep those go away... I could post another version, but it sounds like this isn't desired anyway - so I won't pursue it too much. Just figured it would be better to have 2.12 instead of 2.11.90 in the caps/replies that we store. The details of CPU differences seem to always be a given. We don't "filter" the initial posting based on it so requiring any update posted by someone using different hardware would seem to be overkill especially since it doesn't really seem to matter. John BTW: It also seems spice* type flags/bits only show up in certain environments - so that perhaps too could be considered for some sort of mocking. Something that's different between the s390x results posted upstream as well as the x86_64 results I created.