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 <arm...@redhat.com> > Tested-By: Benoit Canet <ben...@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
signature.asc
Description: OpenPGP digital signature
