[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-API] Re: [Xen-cim] Xen-API update
On Fri, Feb 02, 2007 at 10:26:23AM -0700, Jim Fehlig wrote: > Ewan Mellor wrote: > > Here's a quick update on the Xen-API work; I thought that with the large > > number of changesets that have gone in today that you might be curious ;-) > > > > Great progress - thanks for all the work :-). > > > We had an internal review of the API last week here at XenSource, and what > > you've seen today is the result of that. The goal is to have an interface > > in > > Xen 3.0.5 that we will call the Xen-API 1.0, and that we will maintain in a > > backwards-compatible fashion for the long term. With that in mind, some of > > our "future hopes" that were still unimplemented have been bumped out, and > > where we felt that we needed more flexibility, we've made provision for that > > too. I think that API that we've settled on is in good shape, and is > > certainly something that we can stand behind, and maintain going forward. > > > > I've still got a few more changes to push through over the next day or two, > > and when that's done I'll be marking this API version 0.9, to emphasise the > > approaching deadline. > > > > If you've not already done so, now is the time to try out what we've got. > > This is the _only_ API for Xen that will be maintained in the long term, so > > if > > there's something that you need for your product or your pet project, now is > > the time to shout! We have both Python and C client-side bindings in the > > tree, and a number of example scripts to get you started, and I'd be very > > interested in your feedback. > > > > The host class could use a capabilities field, perhaps a set of strings > describing supported guests - similar to 'xen_caps' field produced by > 'xm info'. Yeah that's critical info if apps want to sanity check what kernels they present to a user as bootable on a host. > We've talked in the past about changing config of running guest vs > changing its stored config. I would like to hotplug memory, cpu, disks, > etc on a running guest but have it use stored config on next activation. > Likewise it would be useful to change the stored config, regardless of > guest state, for application on next activation. I think that would be very useful for a number of use cases. I think I'd previously suggested that for those kind of attributes, we'd want the API to take an extra 'scope' argument, allowing a bitwise or of two constants SCOPE_CONFIG or SCOPE_GUEST. Which would let us say affect running guest only, affect config file only, or affect both guest & config. 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |