[libvirt] Missing blockJobInfo() method from v1.2.5 Python bindings?

[Kashyap Chamarthy]

On Tue, Oct 04, 2016 at 03:08:24PM +0200, Michal Privoznik wrote:
> On 04.10.2016 10:43, Kashyap Chamarthy wrote:

[...]

> > Now try to find out what is present in v1.2.5 by quickly building the
> > bindings for that tag:
> > 
> >     $ git checkout v1.2.5
> >     $ python setup.py build
> > 
> > Hmm, once built, there's no blockJobInfo() method in build/libvirt.py!
> > (When I mentioned this on #virt, OFTC, Cole confirmed he could reproduce
> > the behavior, too.  Not sure if it's a regression in v1.2.5.)
> 
> I've bisected this one down to 8e09c79a07b097a6ba9af83be4916fb9c9538500:
> 
> $ git describe --contains 8e09c79a07b097a6ba9af83be4916fb9c9538500
> v1.2.10^0
> 
> It's a result of a split of python bindings we made a long time ago.

Ah-ha, thanks for bisecting.
 
> > However, the libvirt "glue code" for libvirt_virDomainGetBlockJobInfo()
> > exists in libvirt-python/libvirt-override.c, so checking there (again,
> > for v1.2.5), we see:
> > 
> >    4755     if (c_ret == 0) {
> >    4756         return dict;
> >    4757     } else if (c_ret < 0) {
> >    4758         Py_DECREF(dict);
> >    4759         return VIR_PY_NONE;
> >    4760     }
> > 
> > IIUC, the VIR_PY_NONE means it raises an exception (libvirtError).
> > 
> 
> Correct, the exception is raised in C API fails. Note, that it is not
> considered a failure if there's no job running (in which case an empty
> dict is returned).

Yep, that's clear already now that it's tri-state:

If virDomainGetBlockJobInfo():

  - returns -1 == Python None (which means libvirtError)
  - returns 0  == An empty dict
  - returns 1  == Fully populated dict

-- 
/kashyap