[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] tests/acceptance: fix timeout for vm.wait
From: |
Pavel Dovgalyuk |
Subject: |
Re: [PATCH] tests/acceptance: fix timeout for vm.wait |
Date: |
Thu, 3 Dec 2020 09:29:10 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
On 02.12.2020 18:22, John Snow wrote:
On 12/2/20 1:31 AM, Pavel Dovgalyuk wrote:
This patch adds timeout parameter to vm.wait() calls, because the
default
value is just 30 seconds, and tests may last for more time.
This doesn't sound right -- the timeout isn't meant to be for the
entire duration of the test, the timeout is from the time of issuing
a shutdown command until the time the VM actually shuts down.
Ideally, that should not take a particularly long time in a
well-behaved test.
Why is it lasting longer than 30 seconds?
These are complex Linux boot&execution tests.
Such loading process could take more than 30 seconds.
E.g., BootLinux tests have timeout of 900 seconds.
This timeout should only count towards the time spent *shutting down*,
not the time to run the entire test. 30 seconds used to be enough time
for this to happen on gitlab, if it's taking longer than that I am
worried that something has gone wrong.
Where were the failures observed, and on what tests? Are there logs I
can review?
I've got your point. You were right.
The problem was with new long-lasting record/replay tests:
if record:
cloudinit.wait_for_phone_home(('0.0.0.0', self.phone_home_port),
self.name)
vm.shutdown()
logger.info('finished the recording with log size %s bytes'
% os.path.getsize(replay_path))
else:
vm.wait(None)
logger.info('successfully fihished the replay')
Replay phase here waits for shutdown for the whole period of Linux boot
and execution. We don't check any VM output and just wait for finishing
the replay.
Smaller RR tests include "self.wait_for_console_pattern" during replay
and therefore can't have problems with this timeout.
Pavel Dovgalyuk