On 06/28/2018 03:31 AM, Markus Armbruster wrote:
Peter Xu <pet...@redhat.com> writes:
On Tue, Jun 26, 2018 at 07:21:49PM +0200, Markus Armbruster wrote:
I fooled around a bit, and I think there are a few lose ends.
[...]
Talking to a QMP monitor that supports OOB:
$ socat UNIX:test-qmp READLINE,history=$HOME/.qmp_history,prompt='QMP> '
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 12, "major": 2}, "package":
"v2.12.0-1703-gb909799463"}, "capabilities": ["oob"]}}
QMP> { "execute": "qmp_capabilities", "arguments": { "oob": true } }
{"error": {"class": "GenericError", "desc": "Parameter 'oob' is
unexpected"}}
QMP> { "execute": "qmp_capabilities", "arguments": { "enable": ["oob"] } }
{"return": {}}
QMP> { "execute": "query-qmp-schema" }
{"error": {"class": "GenericError", "desc": "Out-Of-Band capability requires
that every command contains an 'id' field"}}
Why does every command require 'id'?
Why am I asking? Requiring 'id' is rather onerous when you play with
QMP by hand.
Possible solutions other than requiring "id":
1. Make out-of-band responses recognizable
Just like we copy "id" to the response, we could copy "run-oob", or
maybe "control".
Solves the "match response to command" problem, doesn't solve the
"match COMMAND_DROPPED event to command" problem.
Permit me a digression. "control": { "run-oob": true } is awfully
verbose. Back when we hashed out the OOB design, I proposed to use
"exec-oob" instead of "execute" to run a command OOB. I missed when
that morphed into flag "run-oob" wrapped in object "control". Was it
in response to reviewer feedback? Can you give me a pointer?
It's not too late to change back. Since OOB is still new to 3.0, we
could indeed go with a shorter invocation of 'exec-oob' (and I'd
actually be in favor of such a change).
The counterpart to "exec-oob" would be "return-oob" and "error-oob".
Hmm.
In other words, the change in the keyword of the response will let you
know that it is replying to the most recent oob command. This works
well if we guarantee that we never have more than one unprocessed oob
command in the pipeline at a time; but fails if oob commands can be
threaded against one another and start replying in a different order
than original submission. Or, we could state that if you use
'exec-oob', then 'id' is mandatory (and 'id' in the 'return' or 'error'
is then sufficient to tie it back); but when using plain 'execute', 'id'
remains optional.
2. Do nothing; it's the client's problem
If the client needs to match responses and events to commands, it
should use the feature that was expressly designed for helping with
that: "id".
Note that QMP's initial design assumed asynchronous commands,
i.e. respones that may arrive in any order. Nevertheless, it did not
require "id". Same reasoning: if the client needs to match, it can
use "id".
As so often when "do nothing" is a viable solution, it looks mighty
attractive to me :)
Indeed, although the documentation should still be explicit on
recommending the use of 'id' when oob is enabled.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
