From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36127) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zws3n-00038k-Gw for qemu-devel@nongnu.org; Thu, 12 Nov 2015 08:37:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zws3k-00025S-Ae for qemu-devel@nongnu.org; Thu, 12 Nov 2015 08:37:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46453) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zws3k-00025L-2q for qemu-devel@nongnu.org; Thu, 12 Nov 2015 08:37:04 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id C5822A0B3E for ; Thu, 12 Nov 2015 13:37:03 +0000 (UTC) References: <1447291062-11011-1-git-send-email-eblake@redhat.com> <871tbvtrwi.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <564495FF.1060700@redhat.com> Date: Thu, 12 Nov 2015 06:37:03 -0700 MIME-Version: 1.0 In-Reply-To: <871tbvtrwi.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MUcgTP8q5m5MSw1jgPfs9HNQsbDUOm3kx" Subject: Re: [Qemu-devel] [PATCH for-2.5 0/4] Expose ErrorClass through introspection List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MUcgTP8q5m5MSw1jgPfs9HNQsbDUOm3kx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/12/2015 03:48 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> I noticed that introspection was not documenting either >> qmp_capabilities nor the ErrorClass enum. I think this is worth >> fixing for 2.5 when introspection is brand new, so that if we later >> extend the ErrorClass enum or add future capability negotiation (and >> in particular if such additions get backported in downstream builds), >> a client will be able to use introspection to learn whether the new >> features are supported, regardless of the qemu version. >> >> Note that this also adds qmp_capabilities to 'query-commands'. >> >> Yes, this is borderline, and you may decide that it doesn't deserve >> to be called a bug and should wait for 2.6. >=20 > Before I discuss the error class proposal in more detail, a preliminary= > remark: error classes are a leftover from the days of "rich" error > objects, and any new use of an error class other than > ERROR_CLASS_GENERIC_ERROR is immediately suspect. I'm not saying that > we won't add such uses anymore, just that there's a significant bar to > overcome, which we haven't for quite some time now. >=20 > I think I could be persuaded that a client might be able to use > knowledge on what error classes a specific command can produce. Of > course, presence of an error class doesn't tell what actual error > conditions map to it, i.e. the client still needs to make assumptions o= n > the meaning of error classes. Humans make those, too, but humans can > read the contract in the comments. Indeed - knowing the global set of possible errors is NOT the same as knowing the set of command-specific errors; and the latter is more likely to be useful. But exposing the latter would require per-command documentation in the .json files, and is certainly not doable in time for 2.5. >=20 > The value of a global list of error classes seems even more dubious, > though. Existence of an error class by itself guarantees nothing. How= > would a client use the information? Assume that existence of a class > implies a certain command uses it in a certain way? That's an even > bigger jump than above. >=20 > I guess using the presence or absence of an error class as a witness fo= r > a certain feature or behavior could work. Seems practical when the > written contract guarantees the connection between the two (de jure > connection), or the commit that introduces the feature or behavior also= > adds or removes the error class (de facto connecton). This applies bot= h > to a global list of error classes and to per-command lists. >=20 [snip good examples] >=20 > None of these examples is a particularly convincing use case. Can you > think of better ones? No. >=20 > Finally, what happens if error class introspection misses 2.5 and makes= > a later version? >=20 It would not be the first time that libvirt has been coded along the lines of "if the information is available, trust it; if not, go by a hard-coded list that matched the upstream state prior to the information being made available". It's a bit more work on clients, but not insurmountable. > If we add a global error class list like this patch does, a client has > to assume that anything that doesn't has one has the usual error > classes: GenericError, CommandNotFound, DeviceEncrypted, > DeviceNotActive, DeviceNotFound, KVMMissingCap[*]. Whether "doesn't ha= s > one" is "doesn't has one in query-qmp-schema" or "doesn't even have > query-qmp-schema" doesn't matter. Correct - a client can easily hard-code the correct information for all older qemu (at worse, it will miss an error case that has been backported - but in all likelihood, if backporting an error was that important, downstream could also backport the way to introspect for it). >=20 > If we add per-command error class lists, it's the same, only the > assumptions become a bit more involved. >=20 > Of course, the fewer discernible versions of introspection we have, the= > better. If we can figure out what we need in time to get it into the > very first version, great! But it's awfully late for 2.5, and I'm not > at all sure we know what we need. Perhaps we can find out quickly, but= > let's not rush the job. >=20 >=20 > [*] Ancient versions may also have MigrationExpected (see above), but > backporting introspection that far, but not backporting the fix for the= > migration stop/cont race would be insane. Therefore, I agree with you that there is no rush to get this into 2.5. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --MUcgTP8q5m5MSw1jgPfs9HNQsbDUOm3kx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWRJX/AAoJEKeha0olJ0NqY+wIAJcZRYwnKYllhFFzFdJ5G+QJ 9njkhvolIH9ZmggAow0OqQm802GpDDHpoHU17/bnpI9kewaS9PyhaufrBShAWF7N KkCPDvxA/X22JpJzlRnHOn/LN5Wsn2/El9C2ALR3DPzJtibRuHoSG5eOylh2RVnL 4t73OXqtys+v9Skk+Dx0x3Jt+yaVBh61rrs8Bvy1wrE3EoYX+O1oGQwRRvZW1kri O2kYcyo+Fznw+iQKi9IMNoMnKxDsSL0ivVCMDDw9oGwui/7YRGZzrRuvPpYOrCfX pUDC7dvVrK3smfHyHgxmJ38mpW7H7sSBZleurCa993mdO1qU6JkwPNN60g9CsQE= =U4Fq -----END PGP SIGNATURE----- --MUcgTP8q5m5MSw1jgPfs9HNQsbDUOm3kx--