On Fri, Nov 24, 2006 at 03:54:56PM +0000, Daniel P. Berrange wrote:
> On Fri, Nov 24, 2006 at 10:58:12AM +0000, Ewan Mellor wrote:
> > On Fri, Nov 24, 2006 at 10:42:53AM +0000, John Levon wrote:
> >
> > > On Fri, Nov 24, 2006 at 10:28:43AM +0000, Keir Fraser wrote:
> > >
> > > > release candidates for 3.0.4 once or twice a week until we have a tree
> > > > suitable for final release (hopefully by the middle of December).
> > > > Meanwhile
> > >
> > > Does this mean we have less than a month until the Xen API work is
> > > frozen, as was previously the plan for 3.0.4? We're still discussing
> > > aspects of it and AFAIK there's still a lot of work to do in just
> > > finishing defining it, never mind coding it or any "can I actually
> > > program against this" stuff.
> >
> > No (sorry for the confusion). Xen 3.0.4 will contain a "preview" of the
> > Xen-API (i.e. what we've got now) but this will not be the final version of
> > the protocol or data-model, and will not be declared stable or supported.
> > We
> > will ensure that the 3.0.3 protocols are supported in 3.0.4, and will take
> > the
> > time during this freeze to make sure that backwards compatibility to
> > 3.0.3-based clients is all in place.
> >
> > Xen 3.0.4 _will_ contain a working version of "the lifecycle patches", that
> > is, the xm new, start, shutdown, delete, suspend, and resume functionality.
>
> Before 3.0.4 comes out, there are a couple of fixes we previously discussed
> on xen-api to ensure the lifecycle patches don't break semantics of the
> existing SEXPR / XMLRPC APIs.
>
> http://lists.xensource.com/archives/html/xen-api/2006-10/msg00009.html
Yes, we'll get those fixed for 3.0.4.
> It has also previously been mentioned that XenSource were planning some
> work on xenstored to address the terrible performance of its transaction
> code. It'd be nice to see that in 3.0.4 if its ready ?
There are two different fixes for performance problems that you've been
suffering. One is a general improvement to xenstore to improve transaction
performance -- I'm afraid that that one isn't going to be ready for 3.0.4.
The other fix, which is in unstable now, is a fix to xm list so that it does
not hit the store unnecessarily. xm list now explicitly sets a flag to
indicate whether it is doing a "short" or a "long" list, and the short one
does not hit the store at all. This improves the performance of that call by
a very large factor. You should consider setting that flag yourself in new
applications.
Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|