[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-block] [PATCH RFC] qemu-io: Prefer stderr for err
From: |
Nir Soffer |
Subject: |
Re: [Qemu-devel] [Qemu-block] [PATCH RFC] qemu-io: Prefer stderr for error messages |
Date: |
Thu, 13 Dec 2018 19:44:47 +0200 |
On Thu, Dec 13, 2018 at 4:05 PM Kevin Wolf <address@hidden> wrote:
> Am 13.12.2018 um 11:47 hat Daniel P. Berrangé geschrieben:
> > On Thu, Dec 13, 2018 at 01:52:29AM +0200, Nir Soffer wrote:
> > > On Thu, Dec 13, 2018 at 12:13 AM Eric Blake <address@hidden> wrote:
> > > >
> > > > When a qemu-io command fails, it's best if the failure message
> > > > goes to stderr rather than stdout.
> > >
> > > This makes sense, but it will break users like this:
> > >
> > >
> https://github.com/oVirt/vdsm/blob/a2836b1d58ffaa0f48cc9c814b6002161a81f044/tests/storage/qemuio.py#L45
> > >
> > > We need a way to detect qemu-io verification failures, maybe a special
> > > exit code?
> > >
> > > 0 - verification succeeded
> > > 1 - verification failed
> > > 2 - other error (e.g no such file)
> >
> > This makes sense. We should *never* expect applications to parse the
> > messages on stdout/err, because we reserve the right to change text
> > arbitrarily at any time. So we need to use exit status IMHO.
>
> qemu-io processes more than just a single command. What would the exit
> code be if one of the commands succeeds, one gets an I/O error, and the
> third one succeeds for I/O, but fails pattern verification?
>
> The things is, qemu-io was never meant to be used by other
> applications that need to process the results, it's a tool for testing
> and debugging. If we had meant it to be used by other programs, we would
> have given it a machine-friendly interface.
>
> The machine-friendly interface to the QEMU block layer is qemu-nbd.
>
nbd is awesome, but much more complicated to use for testing. You need to:
1. start qemu-nbd
2. wait until it is ready
3. use nbd client (we have one now), or connect the qemu-nbd to /dev/ndbX,
which on
Fedora 28 leaves stale /dev/nbdX devices after disconnection
(I reported this few month ago here).
4. finally disconnect and wait until qemu-nbd terminates
qemu-io is so much easier to use, we need to make it more machine friendly.
> > Or, if qemu-io had a way to read data and write it to stdout, we could
> > > compare the data and avoid the need for special exit code.
> >
> > That should be trivial to do, and quite desirable too IMHO - libvirt
> would
> > in fact quite like such a feature, as it would let us support format
> > conversions when using our upload/download APIs, without having to create
> > intermediate files. Alternatively 'qemu-img convert' could allow for
> > /dev/stdin and /dev/stdout as raw files, but that looks considerably
> > harder to implement.
> >
> > For your usecase that feels rather inefficient as you're introducing
> > multiple data copies, which will be bad for large images. Much better
> > if we just make qemu-io set good exit codes.
>
> 'read -v' produces a hex dump on stdout, but you still need to separate
> it from the other output and then parse the hexdump.
>
The hex dump is nice for interactive use, but not for automated tests,
unless
you test by comparing the output of the tool to previously recorded output
like
iotests do. We don't use tool output for testing, it is very fragile and
hard to
maintain.
> The human interface of qemu-io is honestly just not the right tool for
> the job, and adding one-off tweaks to make it a little bit less horrible
> to use for machines isn't the right approach because it's still not a
> proper machine protocol.
>
Add --output json?
Nir
Re: [Qemu-devel] [PATCH RFC] qemu-io: Prefer stderr for error messages, Daniel P . Berrangé, 2018/12/13
Re: [Qemu-devel] [PATCH RFC] qemu-io: Prefer stderr for error messages, Wainer dos Santos Moschetta, 2018/12/13
Re: [Qemu-devel] [PATCH RFC] qemu-io: Prefer stderr for error messages, Kevin Wolf, 2018/12/13