From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAlKL-0002oD-0X for qemu-devel@nongnu.org; Mon, 03 Oct 2011 12:25:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RAlKI-00018U-Vh for qemu-devel@nongnu.org; Mon, 03 Oct 2011 12:25:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35987) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAlKI-00018A-M5 for qemu-devel@nongnu.org; Mon, 03 Oct 2011 12:25:10 -0400 Date: Mon, 3 Oct 2011 17:24:57 +0100 From: "Daniel P. Berrange" Message-ID: <20111003162457.GQ3825@redhat.com> References: <1316443309-23843-1-git-send-email-mdroth@linux.vnet.ibm.com> <4E88C7DB.9090105@linux.vnet.ibm.com> <20111002210802.GC8072@redhat.com> <4E89B0D4.3090203@us.ibm.com> <20111003133802.GD18920@redhat.com> <4E89BDCE.2010502@codemonkey.ws> <20111003144109.GE19689@redhat.com> <4E89CE20.6050706@codemonkey.ws> <20111003154554.GE20141@redhat.com> <4E89DD2E.700@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4E89DD2E.700@codemonkey.ws> Subject: Re: [Qemu-devel] [RFC] New Migration Protocol using Visitor Interface Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Stefan Berger , Michael Roth , "Michael S. Tsirkin" On Mon, Oct 03, 2011 at 11:05:02AM -0500, Anthony Liguori wrote: > On 10/03/2011 10:45 AM, Michael S. Tsirkin wrote: > >>BTW, putting this info properly into migration stats would probably > >>be pretty useful. > >> > >>Regards, > >> > >>Anthony Liguori > > > >Problem is adding anything to monitor makes me worry > >about future compatibility so much I usually just give up. > >IMO we really need a namespace for in-development experimental > >commands, like "unsupported-XXX", this would belong. > > Or just make all of QMP unsupported across any given version. I'm > not kidding about that actually. > > If we document what the protocol is for any given version, then a > layer like libvirt can deal with providing a consistent interface. > > I often wonder who we're trying to preserve compatibility for. Part > of libvirt's mission statement is providing a stable API so why not > leverage that mission and get us out of the compatibility business. You are correct, that ultimately libvirt should be isolating applications from any changes in QEMU's monitor protocol that take place across versions. We just ask that QEMU try not to make too many gratuitous changes, if it is reasonable to avoid them without negative impact on QEMU. The more time we have to spend adding support for different commands across each QEMU release, the less time we have to spend on adding useful features elsewhere. To me the biggest benefit of QMP is not that the commands are to be supported long term, but rather than it is a sanely parsable format with detectable error reporting and asynchronous events. The important thing to us, is not to make semantic changes to any *existing* commands. If an existing command is flawed, either leave it alone & introduce a new one, or if compatibility can't be maintained for some reason remove the old one & introduce a new one with a *new* name to avoid any confusion. So if you have to deprecate some existing QMP commands and introduce new ones to replace them across releases we can & will cope with that in libvirt. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|