Open Stack

On Thu, Oct 06, 2016 at 09:29:41AM -0500, Eric Blake wrote:
> On 10/06/2016 07:58 AM, Kashyap Chamarthy wrote:
> > On Thu, Oct 06, 2016 at 01:32:39AM +0200, Kashyap Chamarthy wrote:
> >> TL;DR
> >> -----
> >>
> >> From the debug analysis of the log below, and discussion with Eric Blake
> >> of upstream QEMU / libvirt resulted in the below bug report:
> >>
> >>   https://bugzilla.redhat.com/show_bug.cgi?id=1382165 --
> >>   virDomainGetBlockJobInfo: Adjust job reporting based on QEMU stats & the
> >>   "ready" field of `query-block-jobs`
> > 
> > When I raised this on libvirt mailing list[0][1], one of the upstream
> > libvirt devs expressed an NACK in adjusting / "deliberately reporting
> > false data in block info structure".  Similar concern was also shared by
> > Matt Booth on #openstack-nova IRC.
> 
> I disagree with that sentiment. 

Interesting, I just noticed your argument here:

    https://www.redhat.com/archives/libvir-list/2016-October/msg00249.html

> I think it is libvirt's responsibility to live up to libvirt's promise
> of virDomainGetBlockJobInfo() (namely, LIBVIRT documents that cur==end
> means the job is stable; and if qemu reports cur==end when the job is
> not stable, then it is libvirt that is lying to the upper user if it
> does NOT munge qemu's results to be accurate).
>
> As it is, we already patched libvirt to munge qemu's 0/0 into 0/1 when
> ready:false, so munging 123/123 into 122/123 when ready:false would just
> be another case of libvirt working around an infelicity of qemu.  There
> is NO INHERENT MEANING to the magnitude of cur and end, nor any
> requirement that end stays the same value across multiple calls to
> virDomainGetBlockJobInfo() - they are ONLY useful for a relative
> comparison of how much work remains to be done.  Munging the results IS
> appropriate.

Understood, this clarifies it, albeit a little messy. 

It indeed seems inconsistent to allow it in one case (like the one you
allude to above, fixed in 988218ca[1]) to adjust (& _not_ falsify, as
you accurately point out) libvirt reporting, but not the other case
(cur==end, "ready": false case when cur != 0).

So I re-opened the upstream libvirt bug[2] in light of your new
comments.
 

[1] http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=988218ca
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1382165 --
    virDomainGetBlockJobInfo: Adjust job reporting based on QEMU stats &
    the "ready" field of `query-block-jobs`

> That said, if you are going to work with existing libvirt that does
> not munge values, then yes, you either have to implement event
> handling or parse XML for the ready status, as existing libvirt's
> virDomainGetBlockJobInfo() is insufficient for the task.

Yep, noted.

Thanks for the great details, as usual.


-- 
/kashyap