qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v6 00/10] qemu.py: Pylint/style fixes


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v6 00/10] qemu.py: Pylint/style fixes
Date: Thu, 24 Aug 2017 13:15:58 +0100
User-agent: Mutt/1.8.3 (2017-05-23)

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.

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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]