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
02:00:14 PM:

> On Thu, Feb 08, 2007 at 01:25:23PM -0500, Stefan Berger wrote:
> 
> > 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.
> 
> No, I mean the version that's in xen-unstable.  There's section
2.24 on error
> handling in there.
> 
> > 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().
> 
> That might be the easiest way, but it's certainly the wrong one!
> 
> This has been discussed a little on the xen-api list before, though
I agree
> that the documentation needs to be updated.  Setting session->ok
back to true
> when you've handled the error is fine.  The intention is to allow
you to chain
> together short groups of calls, and then check for errors at appropriate
> points.  (If you prefer, you can check for errors after every
single call,
> that's fine too.)
> 
> If you're getting a segfault or a glibc-detected error, then that's
clearly a
> bug.  Could you post your code so that I can try it?

I'll try to put something in your test case that triggers
this error.

   Stefan


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