On 3/20/20 6:21 AM, Philippe Mathieu-Daudé wrote:
> On 3/13/20 9:36 AM, Kevin Wolf wrote:
>> Waiting for only 1 second proved to be too short on a loaded system,
>> resulting in false positives when testing pull requests. Increase the
>> timeout a bit to make this less likely.
>>
>> Signed-off-by: Kevin Wolf <kw...@redhat.com>
>> ---
>> tests/qemu-iotests/iotests.py | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tests/qemu-iotests/iotests.py
>> b/tests/qemu-iotests/iotests.py
>> index b859c303a2..7bc4934cd2 100644
>> --- a/tests/qemu-iotests/iotests.py
>> +++ b/tests/qemu-iotests/iotests.py
>> @@ -925,7 +925,7 @@ class QMPTestCase(unittest.TestCase):
>> self.assert_qmp(event, 'data/type', 'mirror')
>> def pause_wait(self, job_id='job0'):
>> - with Timeout(1, "Timeout waiting for job to pause"):
>> + with Timeout(3, "Timeout waiting for job to pause"):
>> while True:
>> result = self.vm.qmp('query-block-jobs')
>> found = False
>>
>
> I wonder if this might be more accurate:
>
> load_timeout = math.ceil(os.getloadavg()[0])
> with Timeout(1 + load_timeout, "Timeout waiting for job to pause"):
> ...
>
> Anyhow:
> Reviewed-by: Philippe Mathieu-Daudé <phi...@redhat.com>
>
They're just tests ... and this is just a worst-case timeout. I don't
think we need to get too cute with it. This only affects cases where the
test (or the binary) is broken and we have to wait without getting a
response for 3 seconds before being able to declare that the test is
indeed broken.
Optimizing this waiting time is probably not helpful; as when the test
is passing we'll never see this delay.
--js
