On Sun, Oct 08, 2006 at 10:00:13PM +0100, Ewan Mellor wrote:
> All,
>
> I have put a tree on Xenbits containing our work-in-progress regarding a
> Xend that supports the new Xen-API. You may pull from this tree using
>
> hg clone http://xenbits.xensource.com/ext/xen-api.hg
>
> This tree contains the new lifecycle work (from the patches sent to
> xen-devel as an RFC a few months ago), and the major part of the work
> required to support the new API and new configuration file format.
Excellant, thanks for making this available.
> Please note that there are a few instances where the old protocol is
> currently broken, or has subtly changed in semantics. The intention for
> Xen 3.0.4 is to preserve the existing XML-RPC protocol, and to support
> all the existing configuration file formats, so rest assured that if
> this tree shows any breakages at the moment, they will be fixed by the
> time Xen 3.0.4 is released. We would appreciate it if you let us know
> about any such breakages.
I've not tested your new tree directly yet, but here's some feedback on
the lifecycle patches based on the last set which were sent to xen-devel
(which I assume are same as those in your new tree)
With the lifecycle patches, 'xm list' and 'GET /xend/domains' will now
include inactive domains as well as active domains. eg
# xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 594 2 r----- 22.2
guest3 -1 400 1 ------ 14.7
This can cause a slight compatability problem because there has previously
been the tacit assumption that "ID" is a unique way to refer to a domain
running on a box. With all inactive domains now returning '-1' this is no
longer valid. So I think that returning inactive domains by default for
commands line 'xm list' or the raw 'GET /xend/domains' may well cause
compatability problems for existing users of this command / API.
Libvirt at least would need to be modified to deal with this change off the
/xend/domains request.
At the same time though, its clearly desirable to have a single API to list
all domains. So I'd like to propose a very slight modification, thus:
1. /xend/domains - only returns active domains, as per current semantics
2. Add support for an optional parameter '?scope=XXXX' where XXX can be
one of 'active', 'inactive', 'all'. eg, 'GET /xend/domains?scope=inactive'
If we follow this through to 'xm list' we could allow
xm list --scope=all
xm list --scope=inactive
xm list --scope=active
Or simplify a little further
xm list --all
xm list --inactive
xm list --active
In the actual listing of domains in XM, I think its probably more desirable
to just have a '-' in the ID column for inactive domains, rather than -1,s
since this indicates more clearly that there is no effective ID for inactive
domains, eg
# xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 594 2 r----- 22.2
guest3 - 400 1 ------ 14.7
Finally, I'd also like to see the 'xend_config_version' field for 'xm info'
incremented from '2' to '3' to allow clients to easily detect that the XenD
they're talking to has this new capability for configs.
There was one other issue, but I can't remember it right now & I don't
think it was a compatability issue anyway.
So aside from the listing of domains stuff the lifecycle patches look pretty
reasonable to me, thus far.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
|
Home