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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Dec 18, 2024 at 04:51:24PM +0100, Thomas Huth wrote:
> 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.

IIUC, we run the migration-test  qtest for *every* softmmu target.

So, assuming you're referring to alpha guest, we were already
exercising it.

The migration qtest as it exists today is pushing the boundaries of
what a qtest is. I'd actually call the migration qtest a functional
test that happens to use the qtest framework for historical reasons.

The only slight thing that makes it not a functional test is that it
is using a specialized guest, which is just the custom boot sector
that dirties ram.

A true migration functional test is conceptually interesting, as we
have had bugs in the past which only hit when using real guest OS
in certain ways. The trouble is that worst bugs have been pretty
niche, such that its unlikely we would have pre-empatively have
a test combination that would have hit them.


Anyway, I think a true functional test for migration is relevant
to keep, as long as we make it clearly different from the qtest.
A simple smoke test using a real Linux guest is different enough
from our hand crafted boot sector that I think it is valuable
coverage. Even better if we make the functional test add *lots*
of different devices.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|