Re: [Xen-API] Xen Management API draft

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

On Fri, Jun 23, 2006 at 09:36:33AM -0400, Mike D. Day wrote:

> Ewan Mellor wrote:
> >Attached is a draft Xen Management API.  This document presents our ideas 
> >in
> >terms of a data model, with an implied binding to XML-RPC calls.  There 
> >are a
> >few examples in there too -- hopefully it's clear how the mapping between 
> >the
> >document and the wire protocol.
> 
> Ewan, I like the API a lot. The storage repository class needs some 
> additional thought. It really requires some dbms-like attributes. I will 
> try to get some more specific feedback on the storage repository class 
> to you in a different note.
> 
> here is some cursory feedback:
> 
> 1.4.1 transport layer
> 
> We should also support bare xml which would enable file redirection
> (stdin and stdout) and the use of ssh.

Sure, OK.

> 1.4.2
> 
> session -
> 
> We should allow optional delegation of authentication to the transport
> layer. For example, use ssh public key authentication instead of a
> userid/password login.

So what does that entail?  You configure your server to allow you to have a
null session object if the connection is received through a UDP socket, or
something like that?

> 1.6 (to do)
> 
> Authorization schema that maps uids to operations on objects.

Of course, Xend has no concept of fine-grained access control at all at the
moment.  That could be quite a lot of work.

> notification - need a notification class and a notification listener
> on the client.

Yes, I think we do (Daniel Berrange raised the same point).

> 2.6.1 VM class
> 
> 
> Need an addition field "profile" that allows the user to classify VMs
> for particular purposes. For example, "web server," "sendmail switch,"
> "dbms host," "devel workstation," etc.
> 
> This should be a list attribute. Might be good to supply some
> enumerated values but also allow values that are not enumerated.

What would you do with this "profile"?

> Clone method needs to have a customization parameter. Simply cloning a
> VM is not sufficient - the clone at minimum needs a different host
> name, network configuration, and changes to various config files.
> 
> One way to customize a cloned image is to patch the
> filesystem. Another is to replace specific files with new versions
> (usually works best for binary files).

Is this something we need to specify at the API level?  Obviously we can
specify that it gets renamed and gets new MAC addresses, but stooging into the
filesystem sounds quite complex.  How would we specify these operations?

> VM needs a migrate method:
> 
> Bool migrate(session id s, vm ref vm, host ref current, host ref
> destination, Bool test)

D'oh!  We probably want a migrate command in there ;-)

> 2.8 Host class
> 
> Host needs additional attributes that will allow automated
> determination that a given host is capable of hosting a given VM.
> 
> For example, a VM may need specific host characteristics beyond CPU: a
> minimum amount of memory, TPM, network bandwidth, and so on.

Do you think that we can fill out the "and so on"?  It would be good to get
something like an exhaustive list here, I guess.

> If the host class has these attributes we can create an addition
> method that automatically determines if a host can host a particular
> vm.
> 
> Bool qualify(session id s, vm ref vm, host ref host)
> 
> 
> 2.9 Class Network
> 
> Network needs additional attributes that provide media
> characteristics of the NIC.
> 
> RO bandwidth integer Bandwidth in mbps
> 
> RO latency integer time in ms for an icmp roundtrip to a host on the
> same subnet.

Do you mean that the node should be continually measuring these things, or
that they get measured at startup, or what?  Isn't measuring bandwidth quite
expensive?

Ewan.

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