Bug 1097968
| Summary: | libvirt-python API baselineCPU doesn't generate exception | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jincheng Miao <jmiao> | |
| Component: | libvirt | Assignee: | John Ferlan <jferlan> | |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 7.0 | CC: | dyuan, gsun, honzhang, jmiao, mzhan, rbalakri, xuzhang | |
| Target Milestone: | rc | |||
| Target Release: | --- | |||
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | libvirt-1.2.7-1.el7 | Doc Type: | Bug Fix | |
| Doc Text: |
Cause:
Returned an integer value in function call when a NULL was expected for proper exception reporting
Consequence:
Invalid arguments to libvirt-python con.baselineCPU will cause an unexpected exception return.
Fix:
Return the correct python value (VIR_PY_NONE).
Result:
The libvirt-python con.baselineCPU API will now correctly return the right value resulting in a proper exception frame when invalid arguments are provided.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1097969 (view as bug list) | Environment: | ||
| Last Closed: | 2015-03-05 07:35:26 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1097969 | |||
|
Description
Jincheng Miao
2014-05-15 01:53:16 UTC
Using upstream - I'm getting the following results - is this what you expect (as it's not really clear to me from your description)? [root@localhost tp-libvirt]# python Python 2.7.5 (default, Feb 19 2014, 13:47:28) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import libvirt >>> con=libvirt.open(None) >>> con.getLibVersion() 1002005 >>> con.baselineCPU([],0) libvirt: error : xmlCPUs in virConnectBaselineCPU must not be NULL Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3191, in baselineCPU if ret is None: raise libvirtError ('virConnectBaselineCPU() failed', conn=self) libvirt.libvirtError: xmlCPUs in virConnectBaselineCPU must not be NULL >>> ret = con.baselineCPU([], 0) libvirt: error : xmlCPUs in virConnectBaselineCPU must not be NULL Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3191, in baselineCPU if ret is None: raise libvirtError ('virConnectBaselineCPU() failed', conn=self) libvirt.libvirtError: xmlCPUs in virConnectBaselineCPU must not be NULL >>> print ret Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'ret' is not defined >>> Perhaps there's another example of a call that has an exception like you expect that will help me figure out exactly what you're looking for. hmmm...
I reserved a RHEL7.0 beaker system, installed libvirt...
Beaker Test information:
HOSTNAME=dell-pem600-01.rhts.eng.bos.redhat.com
JOBID=654101
RECIPEID=1357164
RESULT_SERVER=[::1]:7085
DISTRO=RHEL-7.0-20140507.0
ARCHITECTURE=x86_64
# yum install libvirt libvirt-python
...
---> Package libvirt-python.x86_64 0:1.1.1-29.el7 will be installed
...
# service libvirtd start
Redirecting to /bin/systemctl start libvirtd.service
# virsh list --all
Id Name State
----------------------------------------------------
# python
Python 2.7.5 (default, Feb 11 2014, 07:46:25)
[GCC 4.8.2 20140120 (Red Hat 4.8.2-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import libvirt
>>> con=libvirt.open(None)
>>> con.getLibVersion()
1001001
>>> con.baselineCPU([],0)
libvirt: error : xmlCPUs in virConnectBaselineCPU must not be NULL
-1
>>> ret = con.baselineCPU([],0)
libvirt: error : xmlCPUs in virConnectBaselineCPU must not be NULL
>>>
#
But if I look at the git history for the 7.0 package - it's supposed to have the commit for bz 912170 which I believe is the fix for this issue. Additionally, if I look at the code in "/usr/lib64/python2.7/site-packages/libvirt.py" I see:
def baselineCPU(self, xmlCPUs, flags=0):
"""Computes the most feature-rich CPU which is compatible with all given host CPUs. """
ret = libvirtmod.virConnectBaselineCPU(self._o, xmlCPUs, flags)
if ret is None: raise libvirtError ('virConnectBaselineCPU() failed', conn=self)
return ret
...
Frustrating... but I think I found the commit I need now in the (now) split libvirt-python code - 8dd64f07ea2c4c53b51a5170f0a3db0c53a094da:
Author: Don Dugger <donald.d.dugger>
Date: Tue Nov 26 16:53:20 2013 +0000
Return right error code for baselineCPU
This Python interface code is returning a -1 on errors for the
`baselineCPU' API. Since this API is supposed to return a pointer
the error return value should really be VIR_PY_NONE.
Signed-off-by: Don Dugger <donald.d.dugger>
diff --git a/libvirt-override.c b/libvirt-override.c
index 3ef81dd..4cc64b7 100644
--- a/libvirt-override.c
+++ b/libvirt-override.c
@@ -4496,13 +4496,13 @@ libvirt_virConnectBaselineCPU(PyObject *self ATTRIBUTE_U
ncpus = PyList_Size(list);
if (VIR_ALLOC_N(xmlcpus, ncpus) < 0)
- return VIR_PY_INT_FAIL;
+ return VIR_PY_NONE;
for (i = 0; i < ncpus; i++) {
xmlcpus[i] = PyString_AsString(PyList_GetItem(list, i));
if (xmlcpus[i] == NULL) {
VIR_FREE(xmlcpus);
- return VIR_PY_INT_FAIL;
+ return VIR_PY_NONE;
}
}
}
@@ -4514,13 +4514,13 @@ libvirt_virConnectBaselineCPU(PyObject *self ATTRIBUTE_U
VIR_FREE(xmlcpus);
if (base_cpu == NULL)
- return VIR_PY_INT_FAIL;
+ return VIR_PY_NONE;
pybase_cpu = PyString_FromString(base_cpu);
VIR_FREE(base_cpu);
if (pybase_cpu == NULL)
- return VIR_PY_INT_FAIL;
+ return VIR_PY_NONE;
return pybase_cpu;
}
Since this is upstream and thus will be in 7.1, I assume you are not looking for a backport to 7.0, correct? If not, then I'll figure what state to change this to... If you are looking for a 7.0 backport, that'll probably mean this needs to be cloned to a 7.0.z stream (although I'm not quite sure of the process). (In reply to John Ferlan from comment #3) > Since this is upstream and thus will be in 7.1, I assume you are not looking > for a backport to 7.0, correct? If not, then I'll figure what state to > change this to... If you are looking for a 7.0 backport, that'll probably > mean this needs to be cloned to a 7.0.z stream (although I'm not quite sure > of the process). Yes, I had set a flag to rhel-7.1.0, and there is no customer needs it be backport-ed to 7.0. Thanks, Jincheng Miao Moving to POST since code is already upstream Verify it as follows. The result is expected. Move its status to VERIFIED. [root@localhost ~]# rpm -q libvirt libvirt-python libvirt-1.2.8-8.el7.x86_64 libvirt-python-1.2.8-5.el7.x86_64 [root@localhost ~]# python Python 2.7.5 (default, Feb 11 2014, 07:46:25) [GCC 4.8.2 20140120 (Red Hat 4.8.2-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import libvirt >>> con=libvirt.open(None) >>> con.baselineCPU([], 0) libvirt: error : xmlCPUs in virConnectBaselineCPU must not be NULL Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3326, in baselineCPU if ret is None: raise libvirtError ('virConnectBaselineCPU() failed', conn=self) libvirt.libvirtError: xmlCPUs in virConnectBaselineCPU must not be NULL >>> ret = con.baselineCPU([], 0) libvirt: error : xmlCPUs in virConnectBaselineCPU must not be NULL Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3326, in baselineCPU if ret is None: raise libvirtError ('virConnectBaselineCPU() failed', conn=self) libvirt.libvirtError: xmlCPUs in virConnectBaselineCPU must not be NULL >>> Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0323.html |