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
|
Home