qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] tests/avocado: Cancel BootLinux tests in case there is no fr


From: Thomas Huth
Subject: Re: [PATCH] tests/avocado: Cancel BootLinux tests in case there is no free port
Date: Mon, 7 Mar 2022 19:31:50 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0

On 07/03/2022 13.50, Daniel P. Berrangé wrote:
On Mon, Feb 28, 2022 at 12:43:25PM +0100, Thomas Huth wrote:
The BootLinux tests are currently failing with an ugly python
stack trace on my RHEL8 system since they cannot get a free port
(likely due to the firewall settings on my system). Let's properly
check the return value of find_free_port() instead and cancel the
test gracefully if it cannot get a free port.

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
  Unfortunately, it still takes > 70 seconds for each and every
  tests from tests/avocado/boot_linux.py to get canceled, so
  tests/avocado/boot_linux.py still renders "make check-avocado"
  for me pretty unusable... looking at the implementation of
  find_free_port() in Avocado, I wonder whether there isn't a
  better way to get a free port number in Python? Brute-forcing
  all ports between 1024 and 65536 seems just quite cumbersome
  to me...

Even in the worst case of testing every single port,
for INET and INET6 and for STREAM and DGRAM sockets,
that find_free_port port completes in a couple of
seconds.

Weird, on my system, the test runs for 70 seconds, just to finally discovered that there was no free port available.

This code is all inherantly racy though, because as
designed it is checking for a port that's available
and then later calls wait_for_phone_home which spins
up a HTTP server listening on the port. The port can
be used in between the check and use. This can be
the case if running many things in parallel on the
host.

It would be better to spin up that server using
kernel port auto-selection at the start eliminating
the race entirely.  Then just record the port that
was allocated and use that when building thue
cloudinit config for the guest.

That sounds much better, indeed... now we just need a volunteer to fix it ;-)

 Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]