[libvirt] [PATCH 01/19] virsh: Add QMP command wrapping for 'qemu-monitor-command'

[Peter Krempa]

On Thu, Dec 12, 2019 at 12:16:11 -0600, Eric Blake wrote:
> On 12/12/19 11:18 AM, Peter Krempa wrote:
> > Issuing simple QMP commands is pain as they need to be wrapped by the
> > JSON wrapper:
> > 
> >   { "execute": "COMMAND" }
> > 
> > and optionally also:
> > 
> >   { "execute": "COMMAND", "arguments":...}
> > 
> > For simple commands without arguments we can add syntax sugar to virsh
> > which allows simple usage of QMP and additionally prepares also for
> > passing through of the 'arguments' section.
> 
> I'd give an example of the new syntax in the commit message:
> 
> virsh qemu-monitor-command domain --qmp COMMAND '{ARGUMENTS...}'
> 
> as shorthand for
> 
> virsh qemu-monitor-command domain '"execute":"COMMAND",
> "arguments":{ARGUMENTS...}}'
> 
> But the sugar is indeed nice (one less layer of {} JSON).
> 
> > 
> > Signed-off-by: Peter Krempa <pkrempa at redhat.com>
> > ---
> >   docs/manpages/virsh.rst | 24 +++++++++++++++++-------
> >   tools/virsh-domain.c    | 32 +++++++++++++++++++++++++++++---
> >   2 files changed, 46 insertions(+), 10 deletions(-)
> > 
> 
> > -    virBufferTrim(&buf, " ", -1);
> > +        if ((opt = vshCommandOptArgv(ctl, cmd, opt)))
> > +            command = opt->data;
> > +        if ((opt = vshCommandOptArgv(ctl, cmd, opt)))
> > +            arguments = opt->data;
> > +
> > +        if (!command || (arguments && vshCommandOptArgv(ctl, cmd, opt))) {
> > +            vshError(ctl, "%s", _("-qmp option requires 1 or 2 arguments"));
> > +            return false;
> 
> Should we allow concatenation and/or magic behavior based on whether the
> second argument starts with '{'?  For example,
> 
> virsh qemu-monitor-command --qmp COMMAND key1=1 'key2="str"'
> 
> could be shorthand for
> 
> virsh qemu-monitor-command '{"execute":"COMMAND", "arguments":{"key1":1,
> "key2":"str"}}'

I thought about this originally, but you also need a way to expose the
'null' field and booleans. Also the necessary double quoting on strings
isn't exactly user friendly given that it's the most common type of
argument.

Also all of the above can only support creating a flat object as
argument so we still need a way to do nested objects or arrays. I agree
though that it's the most common case so any nested or non-default one
can stay JSON-only.

Thus I'll be okay doing this, but I thin we should do something else for
the strings since shell quoting is often confusing to users.