Message ID | 20240209173103.239994-1-kwolf@redhat.com |
---|---|
State | New |
Headers | show |
Series | iotests: Make 144 deterministic again | expand |
On Fri, Feb 09, 2024 at 06:31:03PM +0100, Kevin Wolf wrote: > Since commit effd60c8 changed how QMP commands are processed, the order > of the block-commit return value and job events in iotests 144 wasn't > fixed and more and caused the test to fail intermittently. > > Change the test to cache events first and then print them in a > predefined order. > > Waiting three times for JOB_STATUS_CHANGE is a bit uglier than just > waiting for the JOB_STATUS_CHANGE that has "status": "ready", but the > tooling we have doesn't seem to allow the latter easily. > > Fixes: effd60c878176bcaf97fa7ce2b12d04bb8ead6f7 > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2126 > Signed-off-by: Kevin Wolf <kwolf@redhat.com> > --- > tests/qemu-iotests/144 | 12 +++++++++++- > tests/qemu-iotests/144.out | 2 +- > 2 files changed, 12 insertions(+), 2 deletions(-) Thank you! Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
On Mon, 12 Feb 2024 at 15:20, Stefan Hajnoczi <stefanha@redhat.com> wrote: > > On Fri, Feb 09, 2024 at 06:31:03PM +0100, Kevin Wolf wrote: > > Since commit effd60c8 changed how QMP commands are processed, the order > > of the block-commit return value and job events in iotests 144 wasn't > > fixed and more and caused the test to fail intermittently. > > > > Change the test to cache events first and then print them in a > > predefined order. > > > > Waiting three times for JOB_STATUS_CHANGE is a bit uglier than just > > waiting for the JOB_STATUS_CHANGE that has "status": "ready", but the > > tooling we have doesn't seem to allow the latter easily. > > > > Fixes: effd60c878176bcaf97fa7ce2b12d04bb8ead6f7 > > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2126 > > Signed-off-by: Kevin Wolf <kwolf@redhat.com> > > --- > > tests/qemu-iotests/144 | 12 +++++++++++- > > tests/qemu-iotests/144.out | 2 +- > > 2 files changed, 12 insertions(+), 2 deletions(-) > > Thank you! > > Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Thanks; I'm applying this directly as a CI fix. -- PMM
diff --git a/tests/qemu-iotests/144 b/tests/qemu-iotests/144 index bdcc498fa2..d284a0e442 100755 --- a/tests/qemu-iotests/144 +++ b/tests/qemu-iotests/144 @@ -83,12 +83,22 @@ echo echo === Performing block-commit on active layer === echo +capture_events="BLOCK_JOB_READY JOB_STATUS_CHANGE" + # Block commit on active layer, push the new overlay into base _send_qemu_cmd $h "{ 'execute': 'block-commit', 'arguments': { 'device': 'virtio0' } - }" "READY" + }" "return" + +_wait_event $h "JOB_STATUS_CHANGE" +_wait_event $h "JOB_STATUS_CHANGE" +_wait_event $h "JOB_STATUS_CHANGE" + +_wait_event $h "BLOCK_JOB_READY" + +capture_events= _send_qemu_cmd $h "{ 'execute': 'block-job-complete', 'arguments': { diff --git a/tests/qemu-iotests/144.out b/tests/qemu-iotests/144.out index b3b4812015..2245ddfa10 100644 --- a/tests/qemu-iotests/144.out +++ b/tests/qemu-iotests/144.out @@ -25,9 +25,9 @@ Formatting 'TEST_DIR/tmp.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off co 'device': 'virtio0' } } +{"return": {}} {"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "virtio0"}} {"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "virtio0"}} -{"return": {}} {"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event": "JOB_STATUS_CHANGE", "data": {"status": "ready", "id": "virtio0"}} {"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event": "BLOCK_JOB_READY", "data": {"device": "virtio0", "len": 0, "offset": 0, "speed": 0, "type": "commit"}} { 'execute': 'block-job-complete',
Since commit effd60c8 changed how QMP commands are processed, the order of the block-commit return value and job events in iotests 144 wasn't fixed and more and caused the test to fail intermittently. Change the test to cache events first and then print them in a predefined order. Waiting three times for JOB_STATUS_CHANGE is a bit uglier than just waiting for the JOB_STATUS_CHANGE that has "status": "ready", but the tooling we have doesn't seem to allow the latter easily. Fixes: effd60c878176bcaf97fa7ce2b12d04bb8ead6f7 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2126 Signed-off-by: Kevin Wolf <kwolf@redhat.com> --- tests/qemu-iotests/144 | 12 +++++++++++- tests/qemu-iotests/144.out | 2 +- 2 files changed, 12 insertions(+), 2 deletions(-)