[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 0/7] Switch iotests to using Async QMP
From: |
Hanna Reitz |
Subject: |
Re: [PATCH v3 0/7] Switch iotests to using Async QMP |
Date: |
Wed, 13 Oct 2021 10:45:27 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 |
On 13.10.21 00:34, John Snow wrote:
Based-on: <20211012214152.802483-1-jsnow@redhat.com>
[PULL 00/10] Python patches
GitLab: https://gitlab.com/jsnow/qemu/-/commits/python-aqmp-iotest-wrapper
CI: https://gitlab.com/jsnow/qemu/-/pipelines/387210591
Hiya,
This series continues where the last two AQMP series left off and adds a
synchronous 'legacy' wrapper around the new AQMP interface, then drops
it straight into iotests to prove that AQMP is functional and totally
cool and fine. The disruption and churn to iotests is pretty minimal.
In the event that a regression happens and I am not physically proximate
to inflict damage upon, one may set the QEMU_PYTHON_LEGACY_QMP variable
to any non-empty string as it pleases you to engage the QMP machinery
you are used to.
I'd like to try and get this committed early in the 6.2 development
cycle to give ample time to smooth over any possible regressions. I've
tested it locally and via gitlab CI, across Python versions 3.6 through
3.10, and "worksforme". If something bad happens, we can revert the
actual switch-flip very trivially.
So running iotests locally, I got one failure:
$ TEST_DIR=/tmp/vdi-tests ./check -c writethrough -vdi 300
[...]
300 fail [10:28:06] [10:28:11]
5.1s output mismatch (see 300.out.bad)
--- /home/maxx/projects/qemu/tests/qemu-iotests/300.out
+++ 300.out.bad
@@ -1,4 +1,5 @@
-.......................................
+..............ERROR:qemu.aqmp.qmp_client.qemu-b-222963:Task.Reader:
ConnectionResetError: [Errno 104] Connection reset by peer
+.........................
----------------------------------------------------------------------
Ran 39 tests
[...]
I’m afraid I can’t really give a reproducer or anything. It feels like
just some random spurious timing-related error. Although then again,
300 does have an `except machine.AbnormalShutdown` clause at one
point... So perhaps that’s the culprit, and we need to disable logging
there.
Hanna
- Re: [PATCH v3 3/7] python/aqmp: Remove scary message, (continued)
- [PATCH v3 4/7] iotests: Accommodate async QMP Exception classes, John Snow, 2021/10/12
- [PATCH v3 5/7] iotests: Conditionally silence certain AQMP errors, John Snow, 2021/10/12
- [PATCH v3 6/7] python/aqmp: Create sync QMP wrapper for iotests, John Snow, 2021/10/12
- [PATCH v3 7/7] python, iotests: replace qmp with aqmp, John Snow, 2021/10/12
- [PATCH v3 1/7] python/machine: remove has_quit argument, John Snow, 2021/10/12
- Re: [PATCH v3 0/7] Switch iotests to using Async QMP,
Hanna Reitz <=