From: Wainer dos Santos Moschetta <wainersm@redhat.com>
To: Cleber Rosa <crosa@redhat.com>, qemu-devel@nongnu.org
Cc: "Eduardo Habkost" <ehabkost@redhat.com>,
"Caio Carrara" <ccarrara@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Samuel Ortiz" <sameo@linux.intel.com>
Subject: Re: [Qemu-devel] [PATCH v2 1/2] RFC: Acceptance tests: add the build directory to the system PATH
Date: Thu, 22 Nov 2018 18:15:51 -0200 [thread overview]
Message-ID: <d67d31c9-06fe-1f06-66e0-bc6678212ccd@redhat.com> (raw)
In-Reply-To: <20181121214818.22874-2-crosa@redhat.com>
On 11/21/2018 07:48 PM, Cleber Rosa wrote:
> So that when binaries such as qemu-img are searched for, those in the
> build tree will be favored. As a clarification, SRC_ROOT_DIR is
> dependent on the location from where tests are executed, so they are
> equal to the build directory if one is being used.
On avocado's job.log file I can see the full path of the qemu-img which
was called, but I wonder if it wouldn't be better to log that
information somewhere more explicitly. It wouldn't prevent this patch
from being merged though, it's just an improvement suggestion.
>
> The original motivation is that Avocado libraries such as
> avocado.utils.vmimage.get() may use the matching binaries, but it may
> also apply to any other binary that test code may eventually attempt
> to execute.
>
> Other competing alternatives would be a more explicit path or binary
> registration mechanism, in which we tell the libraries such as
> avocado.utils.vmimage, the binaries to use in advance. I think the
> model proposed here is simpler though, and is not inconsistent with
> the general approach of favoring the built binaries, and falling back
> to binaries available in the system. I'd love to have comments on
> that, though.
IMHO it makes sense to pick the built binaries, falling back to system's
otherwise. Keep it simple (and consistent) unless we eventually need
something robust, I would go for that approach here.
>
> Signed-off-by: Cleber Rosa <crosa@redhat.com>
> ---
> tests/acceptance/avocado_qemu/__init__.py | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/tests/acceptance/avocado_qemu/__init__.py b/tests/acceptance/avocado_qemu/__init__.py
> index 1e54fd5932..3d5190cbab 100644
> --- a/tests/acceptance/avocado_qemu/__init__.py
> +++ b/tests/acceptance/avocado_qemu/__init__.py
> @@ -49,6 +49,15 @@ class Test(avocado.Test):
> self.cancel("No QEMU binary defined or found in the source tree")
> self.vm = QEMUMachine(self.qemu_bin)
>
> + # RFC: avocado.utils.vmimage.get() uses qemu-img, from the
> + # system's PATH, to create a snapshot. This is a transparent,
> + # but implicit way of making sure it finds the qemu-img that
> + # matches the code being tested (as tests it indirectly too).
> + # As for the cleanup, given that in the Avocado test execution
> + # model every test is started in a different process, no
> + # cleanup is needed.
> + os.environ['PATH'] = '%s:%s' % (SRC_ROOT_DIR, os.environ['PATH'])
> +
> def tearDown(self):
> if self.vm is not None:
> self.vm.shutdown()
The boot Linux test (added on patch 02) exits with error when I ran
'make check-acceptance'. I am using Fedora 29 x86_64 which don't have
qemu-img installed system-wide. See below:
------
# make check-acceptance
AVOCADO tests/acceptance
make: *** [/root/qemu/tests/Makefile.include:940: check-acceptance] Error 9
# cat tests/results/latest/results.tap
1..8
not ok 1 /root/qemu/tests/acceptance/boot_linux.py:BootLinux.test
# grep -e 'ERROR.*CmdNotFoundError' tests/results/latest/job.log
2018-11-22 14:51:30,540 stacktrace L0047 ERROR| raise
CmdNotFoundError(cmd, path_paths)
2018-11-22 14:51:30,540 stacktrace L0047 ERROR|
avocado.utils.path.CmdNotFoundError: Command 'qemu-img' could not be
found in any of the PATH dirs: ['/usr/local/bin', '/bin', '/root/bin',
'/sbin', '/usr/libexec', '/usr/local/sbin', '/root/qemu', '/usr/bin',
'/usr/sbin']
2018-11-22 14:51:30,572 test L0984 ERROR|
avocado.utils.path.CmdNotFoundError: Command 'qemu-img' could not be
found in any of the PATH dirs: ['/usr/local/bin', '/bin', '/root/bin',
'/sbin', '/usr/libexec', '/usr/local/sbin', '/root/qemu', '/usr/bin',
'/usr/sbin']
2018-11-22 14:51:30,572 test L0999 ERROR| ERROR
1-/root/qemu/tests/acceptance/boot_linux.py:BootLinux.test ->
CmdNotFoundError: Command 'qemu-img' could not be found in any of the
PATH dirs: ['/usr/local/bin', '/bin', '/root/bin', '/sbin',
'/usr/libexec', '/usr/local/sbin', '/root/qemu', '/usr/bin', '/usr/sbin']
------
The same test finished successfully when I ran with 'avocado run (...)'
though.
- Wainer
next prev parent reply other threads:[~2018-11-22 20:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-21 21:48 [Qemu-devel] [PATCH v2 0/2] Add "boot_linux" acceptance test Cleber Rosa
2018-11-21 21:48 ` [Qemu-devel] [PATCH v2 1/2] RFC: Acceptance tests: add the build directory to the system PATH Cleber Rosa
2018-11-22 20:15 ` Wainer dos Santos Moschetta [this message]
2019-02-06 19:30 ` Cleber Rosa
2019-02-06 22:55 ` Philippe Mathieu-Daudé
2019-02-07 16:40 ` Cleber Rosa
2018-11-21 21:48 ` [Qemu-devel] [PATCH v2 2/2] Add "boot_linux" acceptance test Cleber Rosa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d67d31c9-06fe-1f06-66e0-bc6678212ccd@redhat.com \
--to=wainersm@redhat.com \
--cc=ccarrara@redhat.com \
--cc=crosa@redhat.com \
--cc=ehabkost@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=sameo@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).