3:15 p.m.
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.
NB: I've checked all the other APIs in this file and this is the
only pointer API that is returning -1.
Signed-off-by: Don Dugger <donald.d.dugger(a)intel.com>
---
python/libvirt-override.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/python/libvirt-override.c b/python/libvirt-override.c
index c60747d..b471605 100644
--- a/python/libvirt-override.c
+++ b/python/libvirt-override.c
@@ -4471,13 +4471,13 @@ libvirt_virConnectBaselineCPU(PyObject *self ATTRIBUTE_UNUSED,
ncpus = PyList_Size(list);
if (VIR_ALLOC_N_QUIET(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;
}
}
}
@@ -4489,13 +4489,13 @@ libvirt_virConnectBaselineCPU(PyObject *self ATTRIBUTE_UNUSED,
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;
}
--
1.7.10.4
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano(a)n0ano.com
Ph: 303/443-3786
10:46 a.m.
On Sat, Nov 23, 2013 at 3:15 PM, Don Dugger <n0ano(a)n0ano.com> wrote:
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.
NB: I've checked all the other APIs in this file and this is the
only pointer API that is returning -1.
Signed-off-by: Don Dugger <donald.d.dugger(a)intel.com>
---
python/libvirt-override.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/python/libvirt-override.c b/python/libvirt-override.c
index c60747d..b471605 100644
--- a/python/libvirt-override.c
+++ b/python/libvirt-override.c
@@ -4471,13 +4471,13 @@ libvirt_virConnectBaselineCPU(PyObject *self ATTRIBUTE_UNUSED,
ncpus = PyList_Size(list);
if (VIR_ALLOC_N_QUIET(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;
}
}
}
@@ -4489,13 +4489,13 @@ libvirt_virConnectBaselineCPU(PyObject *self ATTRIBUTE_UNUSED,
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;
}
--
1.7.10.4
ACK. This is correct. But it obviously changes our API so I'm not
really sure how we should handle this, (e.g. document the API as is as
note that its broken or fix it).
--
Doug Goldstein
2:04 a.m.
On Sun, Nov 24, 2013 at 10:46:13AM -0600, Doug Goldstein wrote:
On Sat, Nov 23, 2013 at 3:15 PM, Don Dugger <n0ano(a)n0ano.com>
wrote:
>
> 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.
>
> NB: I've checked all the other APIs in this file and this is the
> only pointer API that is returning -1.
>
> Signed-off-by: Don Dugger <donald.d.dugger(a)intel.com>
> ---
> python/libvirt-override.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/python/libvirt-override.c b/python/libvirt-override.c
> index c60747d..b471605 100644
> --- a/python/libvirt-override.c
> +++ b/python/libvirt-override.c
> @@ -4471,13 +4471,13 @@ libvirt_virConnectBaselineCPU(PyObject *self
ATTRIBUTE_UNUSED,
>
> ncpus = PyList_Size(list);
> if (VIR_ALLOC_N_QUIET(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;
> }
> }
> }
> @@ -4489,13 +4489,13 @@ libvirt_virConnectBaselineCPU(PyObject *self
ATTRIBUTE_UNUSED,
> 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;
> }
> --
> 1.7.10.4
>
ACK. This is correct. But it obviously changes our API so I'm not
really sure how we should handle this, (e.g. document the API as is as
note that its broken or fix it).
I'd say this _also_ depends also on how things are documented. Since
I'm not aware of any documentation explicitly mentioning that this
particular (an only python) API should return -1 in case of allocation
error, I'd say this was an error all along. I'd also say go ahead
with it since this is the proper behavior and I can't imagine a project
where one would rely on this API to return -1 for allocation errors
without a OOM exception instead of all others.
OTOH, though, there are places where similar behavior was already many
times said to be "kept for consistency" (e.g. public *Free() functions
segfaulting with NULL parameter, even though the HACKING file says
they should be no-op in that case), so I must say this is a thing I
cannot clearly resolve with my own logic. In case of voting, I'm all
for cleaning this 3yo mistake.
My $0.02,
Martin
4:45 a.m.
On Sun, Nov 24, 2013 at 10:46:13AM -0600, Doug Goldstein wrote:
On Sat, Nov 23, 2013 at 3:15 PM, Don Dugger <n0ano(a)n0ano.com>
wrote:
>
> 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.
>
> NB: I've checked all the other APIs in this file and this is the
> only pointer API that is returning -1.
>
> Signed-off-by: Don Dugger <donald.d.dugger(a)intel.com>
> ---
> python/libvirt-override.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/python/libvirt-override.c b/python/libvirt-override.c
> index c60747d..b471605 100644
> --- a/python/libvirt-override.c
> +++ b/python/libvirt-override.c
> @@ -4471,13 +4471,13 @@ libvirt_virConnectBaselineCPU(PyObject *self
ATTRIBUTE_UNUSED,
>
> ncpus = PyList_Size(list);
> if (VIR_ALLOC_N_QUIET(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;
> }
> }
> }
> @@ -4489,13 +4489,13 @@ libvirt_virConnectBaselineCPU(PyObject *self
ATTRIBUTE_UNUSED,
> 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;
> }
> --
> 1.7.10.4
>
ACK. This is correct. But it obviously changes our API so I'm not
really sure how we should handle this, (e.g. document the API as is as
note that its broken or fix it).
The implicit expectation with python APIs is that they all raise an
exception if the libvirt call fails. So ACK to this bug fix & we
should put it in maint branches.
That said, please hold off applying this to GIT. We'll put it into
the new libvirt-python git I'm about to push instead.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
9:40 a.m.
On Mon, Nov 25, 2013 at 10:45:38AM +0000, Daniel P. Berrange wrote:
On Sun, Nov 24, 2013 at 10:46:13AM -0600, Doug Goldstein wrote:
> On Sat, Nov 23, 2013 at 3:15 PM, Don Dugger <n0ano(a)n0ano.com> wrote:
> >
> > 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.
...
> >
>
> ACK. This is correct. But it obviously changes our API so I'm not
> really sure how we should handle this, (e.g. document the API as is as
> note that its broken or fix it).
The implicit expectation with python APIs is that they all raise an
exception if the libvirt call fails. So ACK to this bug fix & we
should put it in maint branches.
Much as I hate to raise the issue this assumption is true for pointer
APIs but APIs that return an integer don't raise an exception, they
just return -1. Obviously, changing this behavior would be way too
invasive but documenting this behavior should be done somewhere.
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano(a)n0ano.com
Ph: 303/443-3786
9:48 a.m.
On Mon, Nov 25, 2013 at 08:40:41AM -0700, Don Dugger wrote:
On Mon, Nov 25, 2013 at 10:45:38AM +0000, Daniel P. Berrange wrote:
> On Sun, Nov 24, 2013 at 10:46:13AM -0600, Doug Goldstein wrote:
> > On Sat, Nov 23, 2013 at 3:15 PM, Don Dugger <n0ano(a)n0ano.com> wrote:
> > >
> > > 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.
...
> > >
> >
> > ACK. This is correct. But it obviously changes our API so I'm not
> > really sure how we should handle this, (e.g. document the API as is as
> > note that its broken or fix it).
>
> The implicit expectation with python APIs is that they all raise an
> exception if the libvirt call fails. So ACK to this bug fix & we
> should put it in maint branches.
Much as I hate to raise the issue this assumption is true for pointer
APIs but APIs that return an integer don't raise an exception, they
just return -1. Obviously, changing this behavior would be way too
invasive but documenting this behavior should be done somewhere.
What APIs in particular ? Any API which results in a libvirt error
being set should be translated into an exception in the python. This
is done whether they're APIs returning NULL pointers or -1 ints. If
there are other exceptions to the rule they must be fixed too.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
9:55 a.m.
On Mon, Nov 25, 2013 at 03:48:45PM +0000, Daniel P. Berrange wrote:
On Mon, Nov 25, 2013 at 08:40:41AM -0700, Don Dugger wrote:
> On Mon, Nov 25, 2013 at 10:45:38AM +0000, Daniel P. Berrange wrote:
> > On Sun, Nov 24, 2013 at 10:46:13AM -0600, Doug Goldstein wrote:
> > > On Sat, Nov 23, 2013 at 3:15 PM, Don Dugger <n0ano(a)n0ano.com>
wrote:
> > > >
> > > > 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.
> ...
> > > >
> > >
> > > ACK. This is correct. But it obviously changes our API so I'm not
> > > really sure how we should handle this, (e.g. document the API as is as
> > > note that its broken or fix it).
> >
> > The implicit expectation with python APIs is that they all raise an
> > exception if the libvirt call fails. So ACK to this bug fix & we
> > should put it in maint branches.
>
> Much as I hate to raise the issue this assumption is true for pointer
> APIs but APIs that return an integer don't raise an exception, they
> just return -1. Obviously, changing this behavior would be way too
> invasive but documenting this behavior should be done somewhere.
What APIs in particular ? Any API which results in a libvirt error
being set should be translated into an exception in the python. This
is done whether they're APIs returning NULL pointers or -1 ints. If
there are other exceptions to the rule they must be fixed too.
I'm basing this on code inspection so I could be wrong but if you look
at the Python interface code for libvirt_virDomainSetSchedulerParameters
it checks the return value from virDomainSetSchedulerParameters and,
if it is <0, then the Pythong code returns -1, without raising an
exception.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano(a)n0ano.com
Ph: 303/443-3786
9:59 a.m.
On 11/25/2013 08:55 AM, Don Dugger wrote:
I'm basing this on code inspection so I could be wrong but if you look
at the Python interface code for libvirt_virDomainSetSchedulerParameters
it checks the return value from virDomainSetSchedulerParameters and,
if it is <0, then the Pythong code returns -1, without raising an
exception.
We have two layers of python code. The libvirt-override.c layer returns
None/-1 if a libvirt error is present, then the generated layer turns
that into a python exception to the end user. Look at the generated
libvirt.py for a lot of examples of code that does:
if ret == -1: raise libvirtError ('... failed')
for anything where the C code fails with a -1, and does:
if ret is None: raise libvirtError ('... failed')
for anything where the C code fails with NULL.
The bug that we are fixing here is that we were returning -1 instead of
None for C code that fails with NULL, so the generated wrapper was not
properly throwing a libvirtError.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
10:02 a.m.
On Mon, Nov 25, 2013 at 08:55:12AM -0700, Don Dugger wrote:
On Mon, Nov 25, 2013 at 03:48:45PM +0000, Daniel P. Berrange wrote:
> On Mon, Nov 25, 2013 at 08:40:41AM -0700, Don Dugger wrote:
> > On Mon, Nov 25, 2013 at 10:45:38AM +0000, Daniel P. Berrange wrote:
> > > On Sun, Nov 24, 2013 at 10:46:13AM -0600, Doug Goldstein wrote:
> > > > On Sat, Nov 23, 2013 at 3:15 PM, Don Dugger <n0ano(a)n0ano.com>
wrote:
> > > > >
> > > > > 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.
> > ...
> > > > >
> > > >
> > > > ACK. This is correct. But it obviously changes our API so I'm
not
> > > > really sure how we should handle this, (e.g. document the API as is
as
> > > > note that its broken or fix it).
> > >
> > > The implicit expectation with python APIs is that they all raise an
> > > exception if the libvirt call fails. So ACK to this bug fix & we
> > > should put it in maint branches.
> >
> > Much as I hate to raise the issue this assumption is true for pointer
> > APIs but APIs that return an integer don't raise an exception, they
> > just return -1. Obviously, changing this behavior would be way too
> > invasive but documenting this behavior should be done somewhere.
>
> What APIs in particular ? Any API which results in a libvirt error
> being set should be translated into an exception in the python. This
> is done whether they're APIs returning NULL pointers or -1 ints. If
> there are other exceptions to the rule they must be fixed too.
I'm basing this on code inspection so I could be wrong but if you look
at the Python interface code for libvirt_virDomainSetSchedulerParameters
it checks the return value from virDomainSetSchedulerParameters and,
if it is <0, then the Pythong code returns -1, without raising an
exception.
That code is the low-level module (called libvirtmod) which interfaces
to the C library, and is not called directly by applications.
Applications call the main module (called libvirt) which translates
to the lowlevel module. eg in this case it does:
def setSchedulerParametersFlags(self, params, flags=0):
"""Change the scheduler parameters """
ret = libvirtmod.virDomainSetSchedulerParametersFlags(self._o, params, flags)
if ret == -1: raise libvirtError ('virDomainSetSchedulerParametersFlags()
failed', dom=self)
return ret
so the -1 error is turned into an exception for applications.
The flaw the original patch in this thread was fixing is that the low
level libvirtmod was returning NULL, where the high level libvirt
expected to see -1, so the exception translation was missed.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
10:17 a.m.
On Mon, Nov 25, 2013 at 04:02:37PM +0000, Daniel P. Berrange wrote:
On Mon, Nov 25, 2013 at 08:55:12AM -0700, Don Dugger wrote:
> On Mon, Nov 25, 2013 at 03:48:45PM +0000, Daniel P. Berrange wrote:
> > On Mon, Nov 25, 2013 at 08:40:41AM -0700, Don Dugger wrote:
> > > On Mon, Nov 25, 2013 at 10:45:38AM +0000, Daniel P. Berrange wrote:
> > > > On Sun, Nov 24, 2013 at 10:46:13AM -0600, Doug Goldstein wrote:
> > > > > On Sat, Nov 23, 2013 at 3:15 PM, Don Dugger
<n0ano(a)n0ano.com> wrote:
> > > > > >
> > > > > > 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.
> > > ...
> > > > > >
> > > > >
> > > > > ACK. This is correct. But it obviously changes our API so
I'm not
> > > > > really sure how we should handle this, (e.g. document the API as
is as
> > > > > note that its broken or fix it).
> > > >
> > > > The implicit expectation with python APIs is that they all raise an
> > > > exception if the libvirt call fails. So ACK to this bug fix & we
> > > > should put it in maint branches.
> > >
> > > Much as I hate to raise the issue this assumption is true for pointer
> > > APIs but APIs that return an integer don't raise an exception, they
> > > just return -1. Obviously, changing this behavior would be way too
> > > invasive but documenting this behavior should be done somewhere.
> >
> > What APIs in particular ? Any API which results in a libvirt error
> > being set should be translated into an exception in the python. This
> > is done whether they're APIs returning NULL pointers or -1 ints. If
> > there are other exceptions to the rule they must be fixed too.
>
> I'm basing this on code inspection so I could be wrong but if you look
> at the Python interface code for libvirt_virDomainSetSchedulerParameters
> it checks the return value from virDomainSetSchedulerParameters and,
> if it is <0, then the Pythong code returns -1, without raising an
> exception.
That code is the low-level module (called libvirtmod) which interfaces
to the C library, and is not called directly by applications.
Applications call the main module (called libvirt) which translates
to the lowlevel module. eg in this case it does:
def setSchedulerParametersFlags(self, params, flags=0):
"""Change the scheduler parameters """
ret = libvirtmod.virDomainSetSchedulerParametersFlags(self._o, params, flags)
if ret == -1: raise libvirtError ('virDomainSetSchedulerParametersFlags()
failed', dom=self)
return ret
so the -1 error is turned into an exception for applications.
The flaw the original patch in this thread was fixing is that the low
level libvirtmod was returning NULL, where the high level libvirt
expected to see -1, so the exception translation was missed.
Eric/Daniel-
That's why I distrust code inspection, there's always a hidden gotcha. Tnx
for the clarification.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano(a)n0ano.com
Ph: 303/443-3786
12:40 p.m.
On 12/14/2013 01:36 PM, Daniel P. Berrange wrote:
On Sun, Nov 24, 2013 at 10:46:13AM -0600, Doug Goldstein wrote:
> On Sat, Nov 23, 2013 at 3:15 PM, Don Dugger <n0ano(a)n0ano.com> wrote:
>>
>> 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.
>>
>> NB: I've checked all the other APIs in this file and this is the
>> only pointer API that is returning -1.
>>
>> Signed-off-by: Don Dugger <donald.d.dugger(a)intel.com>
>> ---
>> python/libvirt-override.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/python/libvirt-override.c b/python/libvirt-override.c
>> index c60747d..b471605 100644
>> --- a/python/libvirt-override.c
>> +++ b/python/libvirt-override.c
>> @@ -4471,13 +4471,13 @@ libvirt_virConnectBaselineCPU(PyObject *self
ATTRIBUTE_UNUSED,
>>
>> ncpus = PyList_Size(list);
>> if (VIR_ALLOC_N_QUIET(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;
>> }
>> }
>> }
>> @@ -4489,13 +4489,13 @@ libvirt_virConnectBaselineCPU(PyObject *self
ATTRIBUTE_UNUSED,
>> 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;
>> }
>> --
>> 1.7.10.4
>>
>
> ACK. This is correct. But it obviously changes our API so I'm not
> really sure how we should handle this, (e.g. document the API as is as
> note that its broken or fix it).
The implicit expectation with python APIs is that they all raise an
exception if the libvirt call fails. So ACK to this bug fix & we
should put it in maint branches.
That said, please hold off applying this to GIT. We'll put it into
the new libvirt-python git I'm about to push instead.
I've pushed this to 0.10.2 and 1.0.5 maint branches now.
Thanks,
Cole
3996
days inactive
4017
days old
10 comments
6 participants
participants (6)
-
Cole Robinson -
Daniel P. Berrange -
Don Dugger -
Doug Goldstein -
Eric Blake -
Martin Kletzander