qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Cleber Rosa <crosa@redhat.com>,
	Wainer dos Santos Moschetta <wainersm@redhat.com>
Cc: avocado-devel@redhat.com, Eduardo Habkost <ehabkost@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Avocado notes from KVM forum 2019
Date: Mon, 25 Nov 2019 13:35:13 +0100	[thread overview]
Message-ID: <9b3b2ff0-a3bb-c7ba-d7ce-d178e8fbd5d8@redhat.com> (raw)

Hi Cleber,

Here are my notes from talking about Avocado with various people during 
the KVM forum in Lyon last month.

All comments are QEMU oriented.


1) Working offline

Various people complained Avocado requires online access, and they would 
like to use it offline.

   Maintainer workflow example is:

   - run avocado
   - hack QEMU, build
   - git pull
   - build
   - hack QEMU
   (go offline)
   - hack QEMU
   - build
   - run avocado <- FAILS

Failure is because mainstream added new tests, which got pulled in, and 
the user only notice when running avocado again, but offline.
Test example is boot_linux_console.py, which added various tests from 
other subsystems, so the maintainer has to disable the new tests 
manually to be able to run his previous tests.

Expected solution: skip tests when artifact is not available, eventually 
when the --offline option is used


2) Add artifacts manually to the cache

Not all artifacts can be easily downloadable, some are public but 
require the user to accept an End User License Agreement.
Users would like to share their tests with the documentation about 
where/how to download the requisite files (accepting the EULA) to run 
the tests.


2b) Add reference to artifact to the cache

Group of users might share group of files (like NFS storage) and would 
like to use directly their remote read-only files, instead of copying it 
to their home directory.


3) Provide qemu/avocado-qemu Python packages

The mainstream project uses Avocado to test QEMU. Others projects use 
QEMU to test their code, and would like to automatize that using 
Avocado. They usually not rebuild QEMU but use a stable binary from 
distributions. The python classes are not available, so they have to 
clone QEMU to use Avocado (I guess they only need 5 python files).
When running on Continuous Integration, this is overkill, because when 
you clone QEMU you also clone various other submodules.


4) Warn the user when Avocado is too old for the tests

Some users tried Avocado following the examples on the mailing list and 
the one in some commit's descriptions where we simply show "avocado run 
...". They installed the distribution Avocado package and tried and it 
fails for few of them with no obvious reason (the .log file is hard to 
read when you are not custom to). IIUC their distribution provides a 
older Avocado (69?) while we use recent features (72).

We never noticed it because we use 'make check-venv' and do not test the 
distrib Avocado. While we can not test all distribs, we could add a 
version test if the Avocado version is too old, display a friendly 
message to the console (not the logfile).


That it for my notes.

Eduardo/Wainer, are there other topics I forgot?


Regards,

Phil.



             reply	other threads:[~2019-11-25 12:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-25 12:35 Philippe Mathieu-Daudé [this message]
2019-11-25 13:58 ` Avocado notes from KVM forum 2019 Eduardo Habkost
2019-11-25 14:15   ` Gerd Hoffmann
2019-11-25 15:41     ` Cleber Rosa
2019-11-25 18:08   ` Cleber Rosa
2019-12-10 19:19     ` Willian Rampazzo
2019-11-25 16:27 ` 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=9b3b2ff0-a3bb-c7ba-d7ce-d178e8fbd5d8@redhat.com \
    --to=philmd@redhat.com \
    --cc=avocado-devel@redhat.com \
    --cc=crosa@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=wainersm@redhat.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).