Re: [Xen-devel] [ANNOUNCEMENT] Schedule for Xen 3.0.4

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Fri, Nov 24, 2006 at 04:34:47PM +0000, Ewan Mellor wrote:
> 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.

Excellant, thanks.

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

Ok, I'll try out that approach and see how much diference it makes - it
does sound like it ought to solve the common case problem I see for listing
domains.

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-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel