From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Berger Subject: Re: Re: [PATCH] [XEN-API] Not raising an API error in VTPM destroy method Date: Thu, 8 Feb 2007 14:08:09 -0500 Message-ID: References: <20070208190014.GG2043@leeni.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1173498203==" Return-path: In-Reply-To: <20070208190014.GG2043@leeni.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ewan Mellor Cc: xen-devel , xen-devel-bounces@lists.xensource.com List-Id: xen-devel@lists.xenproject.org This is a multipart message in MIME format. --===============1173498203== Content-Type: multipart/alternative; boundary="=_alternative 00691D248525727C_=" This is a multipart message in MIME format. --=_alternative 00691D248525727C_= Content-Type: text/plain; charset="US-ASCII" xen-devel-bounces@lists.xensource.com 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@lists.xensource.com 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 > > > > > > 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@lists.xensource.com > http://lists.xensource.com/xen-devel --=_alternative 00691D248525727C_= Content-Type: text/html; charset="US-ASCII"
xen-devel-bounces@lists.xensource.com 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@lists.xensource.com 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@us.ibm.com>
> > >
> > > 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@lists.xensource.com
> http://lists.xensource.com/xen-devel
 --=_alternative 00691D248525727C_=-- --===============1173498203== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1173498203==--