[Libvir] XML-RPC support for libvirt

[Daniel Veillard]

On Fri, Mar 10, 2006 at 04:35:11PM -0600, Anthony Liguori wrote:
> On Fri, 10 Mar 2006 17:21:52 -0500, Daniel Veillard wrote:
> One thing I should say is that I'm still contemplating changing the
> XML-RPC interface in Xend to make the libvirt a little easier..

  Well don't think specifically in libvirt terms, but what canonical
interfaces are the most likely to be suitable for apps :-)

> >> Of course, using the xml-rpc code, we now have access to rich fault
> >> information.  Xend never actually returns errors for things and instead
> >> throws exceptions.
> > 
> >   the new error code tries at least to extract the error message when
> > an HTTP POST or GEt fails with an error code, but the XML-RPC should
> > give a far more reliable framework for error handling.
> 
> If I recall correctly, the S-Expression/HTTP errors are always 501
> Internal Server error with no extended error message.  Of course, I may be
> wrong.

There is an error message in the content of the GET/POST returned, I extract
it now, running "make tests" show:

/u/veillard/libvirt/python/tests
## running Python regression tests
libvir: Xen Daemon error : GET operation failed: No such domain test

That is a message output by the library. The python shutdown the 'test'
domain and loop trying to get state every second until a failure. The
failure ends up being reported (i.e. success :-)
  "GET operation failed"
comes from libvirt, while
  "No such domain test"
is the error message extrated from the failed HTTP request, I think it
work alike for POST ones.
Still this is limited and XML-RPC should be better in this respect :-)

> >> For the S-Expression/HTTP protocol, you just get a 501 and have to
> >> return a meaningless error.  With XML-RPC, those exceptions are
> >> actually serialized and sent over the wire.  We may want to explore how
> >> we can make that information available to the user.
> > 
> >   I would say as a buffer at least that's no problem. But exposing
> > the structure of the error stack on the server may be a bit too much.
> 
> What Ewan and I had discussed at the Summit, was standardizing a set of
> exceptions for use as errors.  I think this is a good idea.  I would like
> to always keep the stack trace in the exceptions though as it makes
> debugging Xend considerably simpler.

  Sure sounds a good idea

> For something like libvirt, we could just look at the faultCode and use
> that to build an appropriate error message (based on current locale of
> course).  Perhaps we could also offer an extended error message too that
> included the Xend faultMessage too.

  appropriate error message yes. locale hum I'm not fond of it. libvirt 
is too low in the stack, I would not expect the 'message' to be directly
useful to an user, but one must give as much informations as possible
to the software on top to be able to analyze and present a correct, in-context
error if needed.

> >   Excellent ! Good good !
> > Hopefully we will be able to confront that with what is present in other
> > engines like l4 and QEmu and make sure at least for the 'common' APIs
> > the semantic is similar.
> 
> Oh, L4, good idea :-)  I know just the person to talk to about that too...

  Well Ronald Aigner who joined the list 2 days ago from Desden Univ certainly
seems to come from the l4 group there, but sure get more people on this list,
so we have less risk to fail our API designs ;-)

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/