On 08/24/2017 09:15 AM, Stefan Hajnoczi wrote:
On Tue, Aug 22, 2017 at 04:07:09PM -0300, Eduardo Habkost wrote:
(CCing Cleber and Stefan)
On Tue, Aug 22, 2017 at 07:19:45AM -0300, Philippe Mathieu-Daudé wrote:
[...]
Can we predict how the python scripts will evolve? Only fast-testing?
I guess it depends on how you define "fast". Does "fast-testing"
include a full device-crash-test run (that could take ~30
minutes) or the full set of iotests?
Is there some users hacking on qemu.py unaware they can/should use
libvirt-python?
I believe the existing users of qemu.py wouldn't want to have
dependencies on libvirt or other external modules (e.g. code that
test specific QMP commands and/or is run by "make check").
Yes, most QEMU tests interact with QEMU at a lower level than the
libvirt API. They may exercise new features that are not available via
libvirt so we'd end up bypassing it anyway.
good point,
It is easier to debug a test case that interacts directly with QEMU.
Investigating a failed test where libvirt is involved is more
time-consuming.
another good point.
libvirt and tools built on it, like virt-builder, are good for tests
that need a fully-fledged operating system inside the guest. Avocado
Virt is aimed at higher-level tests involving guests too:
https://avocado-virt.readthedocs.io/en/latest/WritingTests.html
Stefan
