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