Re: [Xen-devel] Re: [PATCH] [XEN-API] Not raising an API error in VTPM destroy method

[Stefan Berger <stefanb@xxxxxxxxxx>]

xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 02/08/2007
10:53:24 AM:

> On Wed, Feb 07, 2007 at 06:37:19PM -0500, Stefan Berger wrote:
> 
> > Don't return an API error if vTPM cannot be destroyed due to
a running
> > VM, but a value indicating failure instead. Adapt python code,
libxen
> > and documentation.
> > 
> > Signed-off-by: Stefan Berger <stefanb@xxxxxxxxxx>
> 
> We have a separate error-returning mechanism -- you should be using
that
> rather than returning an error code.  Take a look at the end
of
> xenapi-datamodel.tex; the error code definitions are there.  In
XendAPI.py,
> you have xen_api_error available, which will marshall an error code
and
> arguments, and in xen/xm/messages there is a translation database
for those
> error messages.

Thanks for pointing this out. I looked at the xenapi-datamodel.tex,
of course, but I mostly find information related to the errors in 1.3.1
and towards the end of the document there's the debug class, but I don't
think you are referring to that one.

The reason why I am actually trying to get rid of
the 'return xen_api_error(...)' statement is that if I am using the C client
library ,libxen, the session->ok parameter changes to 'false' if this
error comes back when for example trying to delete a vTPM from a running
VM. I have tried to make the session usable again by doing 'session->ok
= true'  so I don't have to establish yet another session -- not sure
whether that is an allowed usage model of the session, though. Although
this session works for further transactions the program fails at the point
when the session is cleaned up with glibc complaining about bad memory.
So the easiest way to circumvent this is to have the API return an error
code for failure of the operation using xen_api_success().

  Cheers,
   Stefan

> 
> Cheers,
> 
> Ewan.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
1.3
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel