From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: Request a freeze exception for COLO in v4.6 Date: Thu, 16 Jul 2015 16:00:58 +0100 Message-ID: <20150716150058.GT12455@zion.uk.xensource.com> References: <55A6332D.7070000@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <55A6332D.7070000@cn.fujitsu.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: Yang Hongyang Cc: Wei Liu , Ian Campbell , Wen Congyang , Andrew Cooper , Jiang Yunhong , Dong Eddie , "xen-devel@lists.xen.org" , Gui Jianfeng , Ian Jackson List-Id: xen-devel@lists.xenproject.org On Wed, Jul 15, 2015 at 06:17:17PM +0800, Yang Hongyang wrote: > Hello, > > I would like to request a freeze exception for COLO. > > 1.The benefits > * COLO is a VM fault tolerance solution. Currently Remus provides this > function, but it buffers all output packets, the latency is unacceptable. > COLO addresses the problem, it can greatly improve the VM availability. > * There are 3rd parties interested in this feature, for example Huawei, > they already released Xen/COLO in their product with offline patches. > * If this could go into Xen4.6, it will greatly speed up the production > use of this feature as well as the development. Which could be a huge > benefits to end-users who wants a VM FT solution to provide "non-stop > services" > > 2.The risks > I would say there should be no risk for including this feature into Xen4.6. > Because this feature is only a bolt-on. It should sits in it's own corner > with no harm to the existing code. On the contrary, it improves the > existing code with quite a lot refactoring. > > 3.Further maintenance > Intel and Fujitsu will maintain the code in the future, the feature goes > into upstream does not mean the end of our development, instead it is the > very start of our development, we will continue to improve the feature, > fix bugs and so on. > > 4.Current status > The Libxl migration v2 which we depend on should be merged soon, maybe today. > There're 2 series on list, > One is the prepare patchset, it is mostly refactoring and bugfix, 6/25 been > acked. I would say most of the patchset are ready to be merged. > Another is the main COLO series, it still needs to be carefully reviewed, > but given the fact that this feature is only a bolt-on and we will continue > to improve the code, it should be no harm to merge in the near future. > I'm confident that we could get this ready in the following 1~2 weeks. > Thank you for your email. There are currently 50 patches related to COLO pending reviews and acks (25 pre + 25 COLO itself). Some pre patches are acked but there are still some comments regarding implementation details in the pre patches and COLO itself is still lacking review. Further more, migration v2 is having some issues and has not passed the push gate (this is not really your fault). Given the above situation it's hard for me to justify granting a freeze exception to these 50 patches. However I do understand it is painful for you to carry so many patches and the burden of constantly rebasing so I'm thinking about granting freeze exception to those patches that are pure code motion / low risk refactoring in the pre series, to reduce your load of work. As for the rest patches (rest in pre and COLO itself), I talked to Ian Jackson about this and he's quite optimistic about getting COLO in for 4.7. Ian and Ian, anything to add? What are your opinions? Wei. > -- > Thanks, > Yang. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel