Re: [PULL 00/11] Block layer patches

[Kevin Wolf <kwolf@redhat.com>]

Am 15.11.2022 um 00:58 hat John Snow geschrieben:
> On Mon, Nov 14, 2022 at 5:56 AM Kevin Wolf <kwolf@redhat.com> wrote:
> >
> > Am 11.11.2022 um 20:20 hat Stefan Hajnoczi geschrieben:
> > > > Hanna Reitz (9):
> > > >       block/mirror: Do not wait for active writes
> > > >       block/mirror: Drop mirror_wait_for_any_operation()
> > > >       block/mirror: Fix NULL s->job in active writes
> > > >       iotests/151: Test that active mirror progresses
> > > >       iotests/151: Test active requests on mirror start
> > > >       block: Make bdrv_child_get_parent_aio_context I/O
> > > >       block-backend: Update ctx immediately after root
> > > >       block: Start/end drain on correct AioContext
> > > >       tests/stream-under-throttle: New test
> > >
> > > Hi Hanna,
> > > This test is broken, probably due to the minimum Python version:
> > > https://gitlab.com/qemu-project/qemu/-/jobs/3311521303
> >
> > This is exactly the problem I saw with running linters in a gating CI,
> > but not during 'make check'. And of course, we're hitting it during the
> > -rc phase now. :-(
> 
> I mean. I'd love to have it run in make check too. The alternative was
> never seeing this *anywhere* ...

What is the problem with running it in 'make check'? The additional
dependencies? If so, can we run it automatically if the dependencies
happen to be fulfilled and just skip it otherwise?

If I have to run 'make -C python check-pipenv' manually, I can guarantee
you that I'll forget it more often than I'll run it.

> ...but I'm sorry it's taken me so long to figure out how to get this
> stuff to work in "make check" and also from manual iotests runs
> without adding any kind of setup that you have to manage. It's just
> fiddly, sorry :(
> 
> >
> > But yes, it seems that asyncio.TimeoutError should be used instead of
> > asyncio.exceptions.TimeoutError, and Python 3.6 has only the former.
> > I'll fix this up and send a v2 if it fixes check-python-pipenv.
> 
> Hopefully this goes away when we drop 3.6. I want to, but I recall
> there was some question about some platforms that don't support 3.7+
> "by default" and how annoying that was or wasn't. We're almost a year
> out from 3.6 being EOL, so maybe after this release it's worth a crack
> to see how painful it is to move on.

If I understand the documentation right, asyncio.TimeoutError is what
you should be using either way. That it happens to be a re-export from
the internal module asyncio.exceptions seems to be more of an
implementation detail, not the official interface.

Kevin