Re: [PATCH v2 5/5] tests/functional: Convert the migration avocado test

[Thomas Huth]

On 18/12/2024 14.51, Fabiano Rosas wrote:
> Thomas Huth <thuth@redhat.com> writes:
>
> > Now that we've got a find_free_port() function in the functional
> > test framework, we can convert the migration test, too.
> > While the original avocado test was only meant to run on aarch64,
> > ppc64 and x86, we can turn this into a more generic test by now
> > and run it on all architectures that have a default machine that
> > ships with a working firmware.
>
> I'd rather drop this test. I haven't looked at it in ages and it has
> never been useful.

I think I agree for the scope of the old avocado test - x86, ppc64 and 
aarch64 certainly have better test coverage by the qtest already... but we 
don't have any test coverage for other architectures at all yet, which is 
bad (see below).

So if you like I can change the patch so that the test is not run on x86, 
ppc64 and aarch64 anymore, just on the other architectures that do not have 
test coverage by the qtest yet?

> I haven't been following the development of the
> functional suite so this might not apply this time (fingers crossed),
> but Python tests have always been a pain to work with.

Well, one of the motivations with the functional test framework was to 
simplify things. You can now run the individual tests without any test 
runner at all, what makes debugging way easier (see 
docs/devel/testing/functional.rst for details)!

> About adding more architectures to the set, this is not simply enabling
> more testing, it is also adding workload to maintain these other arches
> that were never tested with migration. Is that something we want?

I think yes. Otherwise the bugs are just dormant until someone hits the 
issue, making bisection way more complicated later.
Remember this one for example:

 https://mail.gnu.org/archive/html/qemu-commits/2023-02/msg00030.html

?

It would have been good to have a migration test for alpha in the CI, then 
we could have prevented that bug from being merged.

> Also note that what is actually prone to break is compatibility between
> versions, which is not covered by this test.

I think it should be possible to add such a check later.

 Thomas