[libvirt] Missing blockJobInfo() method from v1.2.5 Python bindings?
Last night I was trying to check whether blockJobInfo() method will raise an error when it returns 'None' in v1.2.5 libvirt Python bindings. (Eric Blake confirmed on IRC: "the python bindings have, as a general rule, always raised a libvirtError if the C binding code returns None"). Before asking on IRC, I built the bindings and the below is what I noticed. Let's first see what's in current Git master: $ less build/libvirt.py [...] def blockJobInfo(self, path, flags=0): """Get progress information for a block job """ ret = libvirtmod.virDomainGetBlockJobInfo(self._o, path, flags) if ret is None: raise libvirtError ('virDomainGetBlockJobInfo() failed', dom=self) return ret [...] 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.) 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). -- /kashyap
On Tue, Oct 04, 2016 at 10:43:31AM +0200, Kashyap Chamarthy wrote:
Last night I was trying to check whether blockJobInfo() method will raise an error when it returns 'None' in v1.2.5 libvirt Python bindings. (Eric Blake confirmed on IRC: "the python bindings have, as a general rule, always raised a libvirtError if the C binding code returns None").
Before asking on IRC, I built the bindings and the below is what I noticed.
Let's first see what's in current Git master:
$ less build/libvirt.py [...] def blockJobInfo(self, path, flags=0): """Get progress information for a block job """ ret = libvirtmod.virDomainGetBlockJobInfo(self._o, path, flags) if ret is None: raise libvirtError ('virDomainGetBlockJobInfo() failed', dom=self) return ret [...]
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 guess that your libvirt version which was used to generate libvirt-python bindings is too new for libvirt-python-v1.2.5. In general libvirt-python is build-able using libvirt with the same version or older. If you build libvirt-python with newer libvirt the result is undefined, so the build may fail or it may generate wrong files. In your case you have probably libvirt-v1.2.10 or newer, where libvirt.h file was split into separate header files and libvirt-python-v1.2.5 simply don't know about this change. Pavel
On 04.10.2016 10:43, Kashyap Chamarthy wrote:
Last night I was trying to check whether blockJobInfo() method will raise an error when it returns 'None' in v1.2.5 libvirt Python bindings. (Eric Blake confirmed on IRC: "the python bindings have, as a general rule, always raised a libvirtError if the C binding code returns None").
Before asking on IRC, I built the bindings and the below is what I noticed.
Let's first see what's in current Git master:
$ less build/libvirt.py [...] def blockJobInfo(self, path, flags=0): """Get progress information for a block job """ ret = libvirtmod.virDomainGetBlockJobInfo(self._o, path, flags) if ret is None: raise libvirtError ('virDomainGetBlockJobInfo() failed', dom=self) return ret [...]
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.
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). Michal
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
participants (3)
-
Kashyap Chamarthy -
Michal Privoznik -
Pavel Hrdina