|
From: | Jan Richter |
Subject: | Re: [PATCH] avocado: use sha1 for fc31 imgs to avoid first time re-download |
Date: | Thu, 10 Nov 2022 15:57:12 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 |
On 11/10/22 00:26, Philippe Mathieu-Daudé wrote:
On 9/11/22 16:39, Daniel Henrique Barboza wrote:On 10/27/22 06:01, Daniel P. Berrangé wrote:On Thu, Oct 27, 2022 at 09:46:29AM +0200, Thomas Huth wrote:On 24/10/2022 11.02, Daniel P. Berrangé wrote:On Sat, Oct 22, 2022 at 02:03:50PM -0300, Daniel Henrique Barboza wrote:'make check-avocado' will download any images that aren't present in thecache via 'get-vm-images' in tests/Makefile.include. The target that downloads fedora 31 images, get-vm-image-fedora-31, will use 'avocado vmimage get --distro=fedora --distro-version=31 --arch=(...)' to download the image for each arch. Note that this command does not support any argument to set the hash algorithm used and, based on the avocado source code [1], DEFAULT_HASH_ALGORITHM is set to "sha1". Thesha1 hash is stored in a Fedora-Cloud-Base-31-1.9.{ARCH}.qcow2-CHECKSUMin the cache.For now, in QEMU, let's use sha1 for all Fedora 31 images. This will immediately spares us at least one extra download for each Fedora 31 image that we're doing in all our CI runs. [1] https://github.com/avocado-framework/avocado.git @ 942a5d6972906 [2] https://github.com/avocado-framework/avocado/issues/5496Can we just ask Avocado maintainers to fix this problem on their side to allow use of a modern hash alg as a priority item. We've already had this problem in QEMU for over a year AFAICT, so doesn't seem like we need to urgently do a workaround on QEMU side, so we can get Avocado devs to commit to fixing it in the next month.Do we have such a commitment? ... The avocado version in QEMU is completelybacklevel these days, it's still using version 88.1 from May 2021, i.e.there hasn't been any update since more than a year. I recently tried to bump it to a newer version on my own (since I'm still suffering from the problem that find_free_port() does not work if you don't have a local IPv6 address), but it's not that straight forward since the recent versions of avocado changed a lot of things (e.g. the new nrunner - do we want to run tests in parallel? If so it breaks a lot of the timeout settings, I think),so an update needs a lot of careful testing...
Hi Daniel,if the problem of migrating avocado to latest version on qemu is only in parallel run, I would suggest to disable it with `nrunner.max_parallel_tasks` [1]. Even that the differences between avocado legacy runner and nrunner is huge, the migration should be straight forward. So if you have more issues with migration to the nrunner, I would be happy to help you with that.
[1] https://avocado-framework.readthedocs.io/en/latest/config/index.html#nrunner-max-parallel-tasks
- Jan
That it is so difficult to update Avocado after barely more than 1 year is not exactly a strong vote of confidence in our continued use of Avocado long term :-(By the way, Avocado just provided a fix for the problem this patch is tryingto amend: https://github.com/avocado-framework/avocado/pull/5515#issuecomment-1308872846Thanks Jan!Is there an easy way to plug upstream Avocado into QEMU? I would like to test tests/avocado/boot_linux.py:BootLinuxPPC64.test_pseries_tcg to see if the problemis fixed by Avocado upstream.See https://lore.kernel.org/qemu-devel/20200403172919.24621-9-philmd@redhat.com/For your case: -- >8 -- diff --git a/tests/requirements.txt b/tests/requirements.txt index 0ba561b6bd..e17bc3972c 100644 --- a/tests/requirements.txt +++ b/tests/requirements.txt @@ -4,3 +4,3 @@ # Note that qemu.git/python/ is always implicitly installed. -avocado-framework==88.1+-e git+https://github.com/avocado-framework/avocado.git@b31b868c882d4650d3b7d2fbfc9b8ac0f2c3672b#egg=avocado-frameworkpycdlib==1.11.0 --- Regards, Phil.
[Prev in Thread] | Current Thread | [Next in Thread] |