iotests: Fix 219's timing
commit83f90b535a0d5e64056c087aa4022ea35c59bcd0
authorMax Reitz <mreitz@redhat.com>
Wed, 6 Jun 2018 19:06:28 +0000 (6 21:06 +0200)
committerMax Reitz <mreitz@redhat.com>
Mon, 11 Jun 2018 14:18:45 +0000 (11 16:18 +0200)
tree12d907896aa392e81d0c22221e9a8ba99362b77a
parentc1bac161bb7ad27243776e90971c51cc38c2e1b6
iotests: Fix 219's timing

219 has two issues that may lead to sporadic failure, both of which are
the result of issuing query-jobs too early after a job has been
modified.  This can then lead to different results based on whether the
modification has taken effect already or not.

First, query-jobs is issued right after the job has been created.
Besides its current progress possibly being in any random state (which
has already been taken care of), its total progress too is basically
arbitrary, because the job may not yet have been able to determine it.
This patch addresses this by just filtering the total progress, like
what has been done for the current progress already.  However, for more
clarity, the filtering is changed to replace the values by a string
'FILTERED' instead of deleting them.

Secondly, query-jobs is issued right after a job has been resumed.  The
job may or may not yet have had the time to actually perform any I/O,
and thus its current progress may or may not have advanced.  To make
sure it has indeed advanced (which is what the reference output already
assumes), keep querying it until it has.

Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180606190628.8170-1-mreitz@redhat.com
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
tests/qemu-iotests/219
tests/qemu-iotests/219.out