Re: [PATCH 2/3] iotests: port 141 to Python for reliable QMP testing

[Kevin Wolf <kwolf@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2531 bytes --]

Am 18.01.2024 um 15:55 hat Stefan Hajnoczi geschrieben:
> On Wed, Jan 17, 2024 at 07:04:06PM +0100, Kevin Wolf wrote:
> > Am 16.01.2024 um 20:00 hat Stefan Hajnoczi geschrieben:
> > > The common.qemu bash functions allow tests to interact with the QMP
> > > monitor of a QEMU process. I spent two days trying to update 141 when
> > > the order of the test output changed, but found it would still fail
> > > occassionally because printf() and QMP events race with synchronous QMP
> > > communication.
> > > 
> > > I gave up and ported 141 to the existing Python API for QMP tests. The
> > > Python API is less affected by the order in which QEMU prints output
> > > because it does not print all QMP traffic by default.
> > > 
> > > The next commit changes the order in which QMP messages are received.
> > > Make 141 reliable first.
> > > 
> > > Cc: Hanna Czenczek <hreitz@redhat.com>
> > > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > 
> > iotests 297 finds problems with the new Python code:
> > 
> >  === pylint ===
> > +************* Module 141
> > +141:82:0: C0301: Line too long (86/79) (line-too-long)
> > +141:93:0: C0301: Line too long (86/79) (line-too-long)
> > +141:94:0: C0301: Line too long (80/79) (line-too-long)
> > +141:106:0: C0301: Line too long (85/79) (line-too-long)
> > +141:107:0: C0301: Line too long (82/79) (line-too-long)
> > +141:109:0: C0301: Line too long (82/79) (line-too-long)
> > +141:117:0: C0301: Line too long (86/79) (line-too-long)
> > +141:120:0: C0301: Line too long (86/79) (line-too-long)
> > +141:129:0: C0301: Line too long (86/79) (line-too-long)
> >  === mypy ===
> > +141:104: error: Value of type variable "Msg" of "log" cannot be "dict[str, Any] | None"  [type-var]
> > +141:114: error: Value of type variable "Msg" of "log" cannot be "dict[str, Any] | None"  [type-var]
> > +Found 2 errors in 1 file (checked 37 source files)
> 
> I'm not sure how to run this but I manually ran pylint and mypy and
> fixed those errors. Can you share how you ran this?

I already answered this in IRC, but for the record: This is from running
qemu-iotests 297, which is kind of a meta-test that runs the linters on
Python files in qemu-iotests.

> The mypy errors are because the type system cannot express that
> event_wait() only returns None when timeout=0. That's not the case in
> 141 but mypy complains anyway, so I added an assertion that event is not
> None to silence mypy.

Sounds like the right solution to me.

Kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]