[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type
Date: Tue, 25 Apr 2017 10:13:42 +0100
User-agent: Mutt/1.7.1 (2016-10-04)

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.

|: 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 :|

reply via email to

[Prev in Thread] Current Thread [Next in Thread]