From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Migration v2 and related work for 4.6 Date: Wed, 15 Apr 2015 13:52:09 +0100 Message-ID: <1429102329.15516.265.camel@citrix.com> References: <551BD097.2030208@citrix.com> <20150407115910.GC14251@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150407115910.GC14251@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu Cc: Wen Congyang , Vijay Kilari , Andrew Cooper , Ian Jackson , Xen-devel List , Shriram Rajagopalan , Hongyang Yang List-Id: xen-devel@lists.xenproject.org On Tue, 2015-04-07 at 12:59 +0100, Wei Liu wrote: > On Wed, Apr 01, 2015 at 12:03:51PM +0100, Andrew Cooper wrote: > > Hello, > > > > I believe I have CC'd all interested parties. If I have missed anyone, > > please shout. > > > > There are several large series: > > * Cancellable async operations > > * COLO > > > > and a wish to start experimenting with migration on ARM which all > > interact with my large series for migration v2 support in libxc and libxl. > > > > I am working on the libxl side of things, but realise that I am being a > > blockage to the other areas waiting on migration v2. > > > > The current state of the libxc bit is functionally complete. It is > > shipping in two versions of XenServer, has not changed substantially in > > 9 months, and not changed in a backwards incompatible way since v1. > > > > I propose that the libxc series be accepted independently of the libxl > > series. The libxc series is still implemented as an API-compatible > > alternative to legacy migration, and is not enabled by default, meaning > > no change to current users. > > > > However, it will unblock development of ARM migration and COLO, and will > > allow people in the wider community to experiment with migration v2. An > > existing `xl migrate` can be swapped from legacy to migration v2 simply > > by setting an environment variable (for PV guests. HVM requires the > > libxl changed as the handling of the Qemu save record is changing.) > > > > I feel that this is best interest for the community, to get some testing > > available earlier in the development cycle, rather than attempting to > > splice 3 large series in a related area together towards the code freeze. > > > > Thoughts? (especially from a release management point of view) > > > > I've looked at your libxc series. It looks complete. I agree it would be > good to get it in as early as possible. I think the question is more at what point should we flip the switch and make that new code the default without needing to set magic envvars? Or to take it a step further, when can we delete all the old code. Ian.