[libvirt] RFC: Exposing "ready" bool (of `query-block-jobs`) or QMP BLOCK_JOB_READY event

[Peter Krempa]

On Thu, Oct 06, 2016 at 15:51:38 -0500, Eric Blake wrote:
> On 10/06/2016 10:06 AM, Kashyap Chamarthy wrote:
> > On Thu, Oct 06, 2016 at 09:25:26AM -0500, Eric Blake wrote:
> >> On 10/06/2016 06:34 AM, Peter Krempa wrote:
> > 
> > [...]
> > 
> >>> We expose the state of the copy job in the XML and forward the READY
> >>> event from qemu to the users.
> >>
> >> I was not aware of that when I was chatting on IRC yesterday; that's
> >> useful to know, because virDomainGetBlockJobInfo() is NOT exposing that
> >> information at the moment.
> > 
> > That is what this RFC was asking to consider -- whether an [I think it
> > has to be a new one] API should report.
> 
> I think we've answered this one - we don't need a new API, because
> parsing the domain XML already provides the current 'ready':true/false
> status from qemu.
> 
> The existing virDomainGetBlockJobInfo() can't be extended, but it can be
> fixed to quit reporting cur==end when ready:false.

Yes, I agree about this one (although I don't really like it [1]), but
this one will actually fix software not listening for events without any
change.

Any new API would not help since the apps would need to change anyways
thus can use the current correct approach right away even with older
libvirt versions.

Peter

[1]: I'm expecting users to start complaining: "Why is this last byte of
my image taking so long to copy after the rest copied pretty quickly".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20161007/635ebfb9/attachment-0001.sig>