Re: [Xen-API] Xen Management API draft

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

On Sun, Jun 25, 2006 at 04:49:03PM +0100, Daniel P. Berrange wrote:

> On Fri, Jun 23, 2006 at 05:48:08PM -0600, Jim Fehlig wrote:
> > Ewan Mellor wrote:
> > >In particular, we need to get this API into a state so that it is the right
> > >API for Xen-CIM.  We need to think whether libvirt is ready to rely upon 
> > >this
> > >API too.  That would mean moving the hypercalls and Xenstore reads and 
> > >writes
> > >out of libvirt, and pushing it up the stack alongside the other client-side
> > >bindings.
> > >  
> > 
> > Is it realistic to use XML-RPC for tasks such as resource monitoring?  
> > Seems like there should be an optional, lower-latency, lighter-weight 
> > mechanism to retrieve things such as host_cpu.utilisation, 
> > VBD.IO_bandwidth/incoming_kbs, etc.  (Makes me thing of Uncertainty 
> > Principle or Observer Effect, i.e. we crank up cpu utilization by asking 
> > for cpu utilization :-)).  I guess the hypercalls and Xenstore 
> > reads/writes mentioned above would still exist but not be part of the 
> > "guarantees" for Xen.
> 
> Even if there were a optional high peformance channel for these stats,
> it would still be desirable to adjust the APIs to make it possible to
> retrieve all the statistics associated with a guest (CPU, network, 
> disk utilization, etc) in a single XML-RPC call - with the current API
> you'd have to make 3 separate calls - one per guest device you want
> stats from which compounds the performance hit.

That's a good idea -- we'll certainly want to include that.

> > Many of the RPCs return void, e.g. VM.start(), VM.pause(), etc.  How are 
> > failures indicated?  Via the Status and ErrorDescription elements of 
> > return value struct?

Yes, that's right.  Status may be "Failure", implying the presence of the
ErrorDescription array, regardless of the fact that the function returns
void.  It's effectively an exception "thrown" over the wire.

> I would like to see an explicit set of error/exception conditions documented
> against each API. When writing apps against the API it is important to know
> what failure scenarios one has to be aware of. I realize some of the failures
> scenarios won't become clear until the server side implementation is actually
> written, but it ought to be possible to identify an initial set of errors
> for each API, and add others later as they become known. If the errors can
> be enumerated then it ought to be possible to associate an explicit 
> "exception"
> name or number against each, to allow them to be handled without resorting 
> to string comparisons on the description field.

Certainly, I'd like to see a list of expected failures.  We need to be able to
standardise that list so that people can internationalise their clients, in
particular.

> Moving on to a different topic, I've a couple of questions around the topic
> of authentication:
> 
>  * Section 1.4.2 states that all clients must login & initiate a session
>    before making any of the other XML-RPC calls. Is there any provision
>    made for anonymous access. For an application which merely wants to read
>    information about guest VM state it would preferrable to have access
>    without needing to prompt the user for a login/password.
> 
>    Could the requirement to always login be relaxed, and instead annotate
>    each API to indicate whether anonymous (read-only) access is allowed
>
>  * What is the motivation for implementing an explicit login_with_password
>    method rather than utilizing the existing HTTP authentication protocols ?

We discussed this on xen-devel last week -- HTTP auth doesn't seem to be
widely supported, so we didn't want to rely upon it.  Also, this way we can
use the XML-RPC over something other than HTTP (such as a raw unix domain
socket).

>    The proposed login API utilizing a simple username/password pair is quite
>    limiting, preventing the use of any of the more advanced authentication
>    protocols such as challenge/response, public / private key, kerberos 
>    ticket passing.
> 
>    The latter would be particuarly important if the apps using this API want
>    to integrate with any kind of single sign on system. Perhaps it would be
>    possible to define a more advanced login process which could be backed by
>    something like SASL
> 
>      http://www.ietf.org/rfc/rfc2222.txt
>      http://asg.web.cmu.edu/sasl/

What would be involved in making this work?  The username / password is
already a step up for Xen -- how complicated is SASL or similar?

>  * What is the lifetime of sessions ? I assume they persist across distinct
>    HTTP connections for the case where the client isn't using keep-alive.
>    Will there, however, be any form of timeout, after which the client will
>    implicitly be logged out.

No timeout is specified at the moment -- do we want one?  This could be a
configuration option to Xend with little effort.

> Minor question on the 'bios_boot_option' enumeration - rather than hardcoding
> a list of floppy/hd/cdrom, could the bootable device field instead simply be
> a UUID refering to one of the VDB devices defined for the domain ?

That's a nice idea.  We'll certainly roll that into the API.

Cheers,

Ewan.

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api