>> 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.
Nice segway... I've been recently pinged a few times by our Xen CIM consumers about the lack of good errors coming out of our providers (which in turn are limited by what we get back from libxm today), especially in regards to conditions that might cause a create() operation to fail. Do you have a sense today of what errors we might expect to get reported back from libvirt?
Not that this will constitute any sort of meaningful 'requirements' with which to write code, but the following is a list of errors that my Xen CIM consumers handle today for the likes VMWare. I am trying to get more info on under what specific circumstance(s) these are generated...
ERR_SUCCESS
ERR_UNABLE_TO_VERIFY_STATE
ERR_OUT_OF_DISK_SPACE
ERR_BAD_PARAMETER
ERR_VM_CONTROL_OP_FAILED
ERR_INVALID_PARM_NUM
ERR_CANNOT_ACCESS_DISK_FILE
ERR_UNKNOWN
ERR_VIRTUAL_DISK_CREATE_FAILED
ERR_VM_STUCK
ERR_CREDENTIALS_NOT_SET
ERR_UNACCEPTED_CREDENTIALS
ERR_OUT_OF_MEMORY
ERR_WRONG_STATE_FOR_OP
ERR_VM_NOT_FOUND
ERR_HOST_NOT_FOUND
ERR_ACCESS_DENIED
ERR_ALREADY_EXIST
ERR_OPERATION_FAILED
ERR_UNDOABLE_DISK_NOT_SUPPORTED
ERR_VMM_CMD_FORMAT_ERROR
ERR_COMMUNICATION_NOT_ESTABLISHED
ERR_FILE_COPY_FAILED
ERR_NAME_TOO_LONG
ERR_OS_NOT_SUPPORTED
ERR_MOUNT_FAILED_DIR_NOT_EMPTY
ERR_CANT_DISMOUNT_BOOT_OR_SYSTEM
ERR_FILE_IN_USE
I think error reporting is an area where we will definitely want to drive clients' requirements down into the likes of libvirt. Thnx.
- Gareth
Dr. Gareth S. Bestor
IBM Linux Technology Center
M/S DES2-01
15300 SW Koll Parkway, Beaverton, OR 97006
503-578-3186, T/L 775-3186, Fax 503-578-3186
Daniel Veillard <veillard@xxxxxxxxxx>
 |
Sent by: libvir-list-bounces@xxxxxxxxxx 03/10/06 02:21 PM | To: aliguori@xxxxxxxxxxxxxxxxxxxxxxx cc: libvir-list@xxxxxxxxxx Subject: Re: XML-RPC support for libvirt |
On Fri, Mar 10, 2006 at 10:57:59AM -0600, Anthony Liguori wrote:
> Howdy,
Evening ;-)
> I'm about to checkin some XML-RPC code into CVS. The code I'm checking
okay got it. Please add a Changelog entry when you commit to the base :-)
> in won't compile by default (for now) as there's still a little work to
> do but I wanted to get something into the tree. Here are the tasks left:
>
> 1) Convert from dict to s-expressions to handle config returns. Right
> now, the Xend XML-RPC code returns S-Expressions in the form of a
> tuple. We just need a little code to convert from these tuples to
> struct sexpr's.
>
> 2) Integrate my unit tests. I've got a number of unit tests that stress
> the various bits of parsing code. I'd like to add a make check that
> runs these unit tests and a make fullcheck that runs these unit tests
> under valgrind.
>
> 3) Support XML-RPC over a domain socket. Right now I'm using nanohttp
> which doesn't appear to allow different transports. There is some HTTP
> PUT code already in the tree so I could use that if there isn't a more
> clever solution.
>
> 4) Plumb the xend backend functions to XML-RPC. This is really straight
> forward. It's just a matter of converting:
>
> int
> xend_pause(virConnectPtr xend, const char *name)
> {
> return xend_op(xend, name, "op", "pause", NULL);
> }
>
> To:
>
> int
> xend_pause(virConnectPtr xend, const char *name)
> {
> if (xend->xmlrpc)
> return xmlRpcCall(xend->xmlrpc, "xend.domain.pause", "", "s", name)
> else
> return xend_op(xend, name, "op", "pause", NULL);
> }
Okay the steps needed look fairly clear, thanks :-)
> 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.
> 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.
> My current understanding, btw, is that the basic XML-RPC support for
> Xend is going into the tree sometime this week (Ewan is looking at the
> code now) and will be a part of the 3.0.2 release. This means that for
That's waht I was told too :-)
> the 3.0.3 cycle, we'll be defining a standard API. This process will be
> starting soon (within the next couple of weeks hopefully).
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.
Daniel
--
Daniel Veillard | Red Hat http://redhat.com/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
