Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type

["Daniel P. Berrange" <berrange@redhat.com>]

On Mon, Apr 24, 2017 at 09:10:22PM +0200, Markus Armbruster wrote:
> With 2.9 out of the way, how can we make progress on this one?
> 
> I can see two ways to get asynchronous QMP commands accepted:
> 
> 1. We break QMP compatibility in QEMU 3.0 and convert all long-running
>    tasks from "synchronous command + event" to "asynchronous command".
> 
>    This is design option 1 quoted below.  *If* we decide to leave
>    compatibility behind for 3.0, *and* we decide we like the
>    asynchronous sufficiently better to put in the work, we can do it.
> 
>    I guess there's nothing to do here until we decide on breaking
>    compatibility in 3.0.

>From the libvirt POV we'll generally be against QEMU breaking back
compatibility, if there's a viable option which can avoid the back
compat breakage.

Is it possible to do option 1, but have it be an opt-in. ie when
libvirt does the initial QMP greeting, it could issue a command
to active async mode. For simplicity that could be an all-or-nothing
switch - ie makes all commands be async. That way we avoid breaking
any existing libvirt, but give new libvirt the chance to opt-in to
the new way.

Regardless new libvirt will end up having to support both modes of
QMP for 5-10 years...

> 2. We don't break QMP compatibility, but we add asynchronous commands
>    anyway, because we decide that's how we want to do "jobs".
> 
>    This is design option 3 quoted below.  As I said, I dislike its lack
>    of orthogonality.  But if asynchronous commands help us get jobs
>    done, I can bury my dislike.
> 
>    I feel this is something you should investigate with John Snow.
>    Going through a middleman (me) makes no sense.  So I'm going to dump
>    my thoughts, then get out of the way.
> 
>    You need to take care not to get bogged down in the jobs project's
>    complexity.  This is really only how to package up jobs for QMP.
> 
>    With synchronous commands, the job-creating command creates a job,
>    jobs state changes trigger events, and job termination is just
>    another state change.  Job control commands interact with the job.
>  
>    Events obviously need to carry a job ID.  We can either require the
>    user to pass it as argument to the job-creating command (hopefully
>    unique), or have the job-creating command pick one (a unique one) and
>    return it.
> 
>    With asynchronous commands, we could make the asynchronous command
>    the job.  The only difference is that job termination triggers the
>    command response.  When termination is of no interest to anyone but
>    the job's creator, the termination event can be omitted then.
> 
>    Instead of a job ID, we could use the (user-specified and hopefully
>    unique) command ID that ties the command response to the command.
>    Perhaps throw in a monitor ID.
> 
>    To be honest, I'm not sure asynchronous commands buy us much here.
>    But my view is from 10,000 feet, and John might have different ideas.
> 
> Rejecting asynchronous QMP commands is of course design option 2 quoted
> below.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|