From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50577) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RipLm-0000RM-2v for qemu-devel@nongnu.org; Thu, 05 Jan 2012 10:35:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RipLg-00017j-7z for qemu-devel@nongnu.org; Thu, 05 Jan 2012 10:35:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RipLf-00017a-To for qemu-devel@nongnu.org; Thu, 05 Jan 2012 10:35:24 -0500 Message-ID: <4F05C332.7010300@redhat.com> Date: Thu, 05 Jan 2012 08:35:14 -0700 From: Eric Blake 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> In-Reply-To: <20120105121603.309fe735@doriath> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF2179A7BEA3AE63D11E142F4" Subject: Re: [Qemu-devel] [libvirt] QMP: Supporting off tree APIs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Kevin Wolf , aliguori@us.ibm.com, Stefan Hajnoczi , libvir-list@redhat.com, Stefan Hajnoczi , Marcelo Tosatti , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF2179A7BEA3AE63D11E142F4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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.= ) >=20 > 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 work= s. 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 piece= s. 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. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigF2179A7BEA3AE63D11E142F4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPBcMyAAoJEKeha0olJ0NqJr4IAIpEr8reWAXFpmY6giWCidrO qYA1yKgBedhDrgsKa/A3ZhS376DInv2mw+cX1d58/wCi+SQpoD4fAI1KNB5zOkTY LhPqrAHvz+4SBVp0UZuGthBHL9UtlS+3Yz1w9xhfDD3G5LtnBFANHy4vDX7kuypg DbOU+oJqq1DvLsGMi1E1ay94CvdFOSSldrLndUTrajW3KqyWtCSDZSdXFaQA8n7F sgrx1ttLtlytzOE4MRCOVDmPgxtQWpD5qQ2JVbocJ+DGv0h2DiEM4z8Ckgaq/EF7 H7QZ0GthF9WEJBQM6z7c5ryqhcDZTb2n+HN6EPhOsqrAf5aSzqRvlSZWvu7oCBs= =aE4E -----END PGP SIGNATURE----- --------------enigF2179A7BEA3AE63D11E142F4--