qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]