[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [PATCH v2 0/2] Add "boot_linux" acceptance test
From: |
Cleber Rosa |
Subject: |
[Qemu-devel] [PATCH v2 0/2] Add "boot_linux" acceptance test |
Date: |
Wed, 21 Nov 2018 16:48:16 -0500 |
Some hopefully useful pointers for reviewers:
=============================================
Git Info:
- URI: https://github.com/clebergnu/qemu/tree/sent/test_boot_linux_v2
- Remote: https://github.com/clebergnu/qemu
- Branch: sent/test_boot_linux_v2
Travis CI Info:
- Build: https://travis-ci.org/clebergnu/qemu/builds/458110642
- Execution results for the test added here:
* https://travis-ci.org/clebergnu/qemu/jobs/458110664#L2043
Previous version:
- http://lists.nongnu.org/archive/html/qemu-devel/2018-09/msg02530.html
Changes from v1:
================
* The commit message was adjusted, removing the reference to the
avocado.utils.vmimage encoding issue on previous Avocado versions
(<= 64.0) and the fix that would (and was) included in Avocado
version 65.0.
* Effectively added pycdlib==1.6.0 to the requirements.txt file,
added on a56931eef3, and adjusted the commit message was also
to reflect that.
* Updated the default version of the guest OS, from Fedora 28 to 29.
Besides possible improvements in the (virtual) hardware coverage,
it brings a performance improvement in the order of 20% to the
test:
With a Fedora 28 guest:
... boot_linux.py:BootLinux.test: PASS (14.23 s)
With a Fedora 29 guest:
... boot_linux.py:BootLinux.test: PASS (11.87 s)
* Removed all direct parameters usage from the test. Because some
parameters and its default values implemented in the test would
prevent it from running on some environments. Example: the "accel"
parameter had a default value of "kvm", which would prevent this
test, that boots a x86_64 OS, from running on a host arch different
than x86_64. I recognize that it's desirable to make tests
reusable and parameterized (that was the reason for the first
version doing so), but the mechanism to be used to define the
architectures that a given test should support is still an open
issue, and has been discussed in other threads. I'll follow up
those discussions with a proposal, and until then, removing those
aspects from this test implementation seemed to be the best option.
A caveat: this test currently adds the same tag (x86_64) and
follows other assumptions made on "boot_linux_console.py", that is,
that a x86_64 target binary will be used to run it. If a user is
in an environment that does not have a x86_64 target binary, it
could filter those tests out with: "avocado run
--filter-by-tags='-x86_64' tests/acceptance".
* Removed most arguments to the QEMU command line for pretty much the
same reasons described above, and by following the general
perception that I could grasp from other discussions that QEMU
defaults should preferrably be used. This test, as well as others,
can and should be extended later to allow for different test
scenarios by passing well documented parameter values. That is,
they should respect well-known parameters such as "accel" mentioned
above, so that the same test can run with KVM or TCG.
* Changed the value of the memory argument to 1024, which based on
my experimentations and observations is the minimum amount of RAM
for the Fedora 29 cloud image to sucessfully boot on QEMU. I know
there's no such thing as a "one size fits all", specially for QEMU,
but this makes me wonder wether a x86_64 machine type shouldn't
have its default_ram_size bumped to a number practical enough to
run modern operating systems.
* Added a new patch "RFC: Acceptance tests: add the build directory
to the system PATH", which is supposed to gather feedback on how to
enable the use of built binaries, such as qemu-img, to code used by
the test code. The specific situation here is that the vmimage,
part of the avocado.utils libraries, makes use of qemu-img to create
snapshot files. Even though we could require qemu-img to be installed
as a dependency of tests, system wide, it actually goes against the
goal of testing all QEMU things from the source/build tree. This
became aparent with tests running on environments such as Travis CI,
which don't necessarily have qemu-img available elsewhere.
Cleber Rosa (2):
RFC: Acceptance tests: add the build directory to the system PATH
Add "boot_linux" acceptance test
tests/acceptance/avocado_qemu/__init__.py | 9 +++++
tests/acceptance/boot_linux.py | 46 +++++++++++++++++++++++
tests/requirements.txt | 1 +
3 files changed, 56 insertions(+)
create mode 100644 tests/acceptance/boot_linux.py
--
2.19.1
- [Qemu-devel] [PATCH v2 0/2] Add "boot_linux" acceptance test,
Cleber Rosa <=