This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-API] Xen Management API draft

To: Anthony Liguori <aliguori@xxxxxxxxxx>
Subject: Re: [Xen-API] Xen Management API draft
From: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Date: Sun, 25 Jun 2006 10:31:13 +0100
Cc: Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 25 Jun 2006 02:31:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <449B1E8D.5090706@xxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
References: <20060622170130.GI25606@xxxxxxxxxxxxxxxxxxxxxx> <449B1E8D.5090706@xxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Thu, Jun 22, 2006 at 05:49:49PM -0500, Anthony Liguori wrote:

> I also reviewed the API document this afternoon.  I'll say that I'm a 
> bit less emphatic about this one (although I still appreciate the effort).
> My basic problem is that this API is huge.  I understand why most of 
> this stuff is included but at the same time, it greatly conflicts with 
> existing systems that already do this (for instance, IBM Director's CIM 
> interfaces).
> What I'd like to see is a minimalistic API that only dealt with Xen 
> specific stuff.  If you wished to have an accompanying API that also 
> provided other system info (via the same model) that would seem like a 
> rather good compromise.

The intention is for this API to be precisely what you would need to be able
to manage Xen hosts and guests, no more, no less.  It's the API that we would
put underneath things like the Xen-CIM providers, so yes, I'm expecting the
services on offer to look similar!

What we want to provide is an object-oriented data model, much the same as
CIM, but lighter-weight where CIM models things that we don't care about, and
including those things that we _do_ care about that CIM hasn't got around to

> We're interested in a minimalistic Xen stack.  So being able to omit the 
> portions of this API that we don't need would be very useful.

I don't think that there's anything in this spec that one could omit, so could
you elaborate here?



xen-api mailing list