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