[libvirt] [PATCH] qemu: blockjob: Don't report block job progress at 100% if job isn't ready

[Kashyap Chamarthy]

On Wed, Jan 30, 2019 at 10:46:24AM +0100, Peter Krempa wrote:
> On Tue, Jan 29, 2019 at 18:52:37 +0100, Kashyap Chamarthy wrote:

[...]

> > Optional, a bit of explanation of "munging the output" at the start (and
> > end) of the job would be useful for those new to these block APIs.
> > 
> > Reading between the lines, and from what I recall Eric explaining once,
> > what you're implying here is: that even if QEMU reported "cur==end", but
> > if the _READY event is not emitted, libvirt manipulates it to report
> > "cur<end".
> > 
> > Thanks for the workaround (because "QEMU is not accurately reporting
> > data") fix.
> > 
> > /me wonders if he could make a reliable reproducer test for this...
> 
> Technically you'll need to patch either libvirt or qemu to do so. E.g.
> add a delay to processing of the READY event from qemu. This is a race
> across two applications which is not easy to reproduce.

Yep, noted.  For now I won't spend time on it.

> Also I really don't want to think this is a solution. This is a dirty
> hack to work around software not willing to adapt to the correct
> approach.

It's not about "not willing" but the "small matter of implementing" it
correctly without regressing. :-)  And I realize it's not a perfect
"solution", that's why I called it a workaround.  And FWIW, Eric seems
to agree that it is reasonable given the circumstances.

> I did not want do do this, but I've found that we do something similar
> for the job startup. I really hate this solution, but given that it's
> two years since I've pointed out that relying on polling the info via
> virDomainBlockJobInfo is broken and apps should use the _READY event
> and it's still an issue today I'm going to do this, but really don't
> want to advertise this as a solution. It's not a solution. It's a
> hack.

Right, at least for Nova, I _did_ notify upstream that the correct way
is to use the events.  It's a matter of prioritizing that task.  (I'll
file a formal bug.)

-- 
/kashyap