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