Re: [PATCH] tests/acceptance: fix timeout for vm.wait

[Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru>]

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