From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ripgo-0002Dy-Ac for qemu-devel@nongnu.org; Thu, 05 Jan 2012 10:57:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ripgi-0005D4-DA for qemu-devel@nongnu.org; Thu, 05 Jan 2012 10:57:14 -0500 Received: from e32.co.us.ibm.com ([32.97.110.150]:47143) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ripgi-0005Cq-7E for qemu-devel@nongnu.org; Thu, 05 Jan 2012 10:57:08 -0500 Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 5 Jan 2012 08:57:07 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q05Fuok6100864 for ; Thu, 5 Jan 2012 08:56:55 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q05Fumgj013356 for ; Thu, 5 Jan 2012 08:56:49 -0700 Message-ID: <4F05C83C.4090707@us.ibm.com> Date: Thu, 05 Jan 2012 09:56:44 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1323784351-25531-1-git-send-email-stefanha@linux.vnet.ibm.com> <1323784351-25531-6-git-send-email-stefanha@linux.vnet.ibm.com> <20120104105911.7e8ca4e4@doriath> <20120105121603.309fe735@doriath> <4F05C332.7010300@redhat.com> In-Reply-To: <4F05C332.7010300@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] QMP: Supporting off tree APIs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Kevin Wolf , Stefan Hajnoczi , libvir-list@redhat.com, Stefan Hajnoczi , Marcelo Tosatti , qemu-devel@nongnu.org, Luiz Capitulino On 01/05/2012 09:35 AM, Eric Blake wrote: > On 01/05/2012 07:16 AM, Luiz Capitulino wrote: >>> I know. We're stuck in a hard place here again because NotSupported >>> has been in the Image Streaming API spec and hence implemented in >>> libvirt for a while now. If we change this then an old client which >>> only understands NotSupported will not know what to do with the >>> Unsupported error. >>> >>> (Unsupported was not in QEMU when the Image Streaming API was defined.) >> >> Let me try to understand it: is libvirt relying on an off tree API and >> we are now required to have stable guarantees to off tree APIs? > > No. Libvirt recognizes the off-tree spelling, but does not rely on it - > after all, the goal of libvirt is to provide the high level action, > using whatever underlying mechanism(s) necessary to get to that action, > even if it means using several different attempts until one actually works. > > If a user has the older libvirt, which only expects the off-tree > spelling, then that user's setup will break if they upgrade qemu but not > libvirt. But that's not a severe problem - they could have only been > relying on the situation if they were using an off-tree build in the > first place, so they should be aware that upgrading qemu is a > potentially risky scenario, and that they may have to deal with the pieces. Right, this is the difference between ABI compatibility and strict backwards compatibility. To achieve ABI compatibility, we need to not overload BLOCK_JOB_COMPLETED to mean something other than libvirt what expects it to mean. We MUST provide ABI compatibility and SHOULD provide backwards compatibility whenever possible. In this case, I'd suggest that in the very least, we should add BLOCK_JOB_COMPLETED to qapi-schema.json with gen=False set. That way it's codified in the schema to ensure we maintain ABI compatibility. That said, I'm inclined to say that we should just use the BLOCK_JOB_COMPLETED name because I don't think we gain a lot by using QMP_JOB_COMPLETED (not that we shouldn't introduce it, but using it here isn't going to make or break anything). With respect to libvirt relying on interfaces before they exist in QEMU, we need to be a bit flexible here. We want to get better at co-development to help make libvirt support QEMU features as the bleeding edge. Forcing libvirt to wait until a feature is fully baked in QEMU will ensure there's always a feature gap in libvirt which is in none of our best interests. Now that we have gen=False support in qapi-schema.json, we can agree to an API and add it to QEMU before we fully implement it. This gives libvirt something to work off of that they can rely upon. Regards, Anthony Liguori > > Newer libvirt can be easily taught to recognize both the off-tree and > stable spellings of the error (checking the stable first, of course, > since that will be more likely as the off-tree qemu builds filter out > over time). At which point, using either the off-tree qemu or the > stable qemu should both work with the newer libvirt. >