Re: [Qemu-devel] [PATCH v2 2.1 1/3] blockjob: Fix recent BLOCK_JOB_READY regression

[Eric Blake <eblake@redhat.com>]

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

On 06/27/2014 11:24 AM, Markus Armbruster wrote:
> Commit bcada37 dropped the (up to now undocumented) members type, len,
> offset, speed, breaking tests/qemu-iotests/040 and 041.
> 
> Restore and document them.  This fixes 040, and partially fixes 041.
> 
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> Tested-By: Benoit Canet <benoit@irqsave.net>
> ---
>  blockjob.c           |  6 +++++-
>  qapi/block-core.json | 15 ++++++++++++++-
>  2 files changed, 19 insertions(+), 2 deletions(-)

Nothing wrong with this commit, but a design issue that I've recently
run into:

what happens if management misses the BLOCK_JOB_COMPLETED event?  How is
it supposed to learn whether the job succeeded or failed?
'query-blockjobs' no longer reports the job (because it is completed),
so all information about the job is lost.  Normally, we've tried hard to
make sure that all information learned from an event can also be polled
(the ideal is use of events to minimize cpu overhead, but to rely on the
poll in situations where events may have been lost such as on a libvirtd
restart).

Should we enhance job failure to be sticky, in that it not only causes
an event, but also remains around so that it can be reported in the next
'query-blockjobs'?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]