[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: |
Marc-André Lureau |
Subject: |
Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type |
Date: |
Tue, 24 Jan 2017 13:43:17 -0500 (EST) |
Hi
----- Original Message -----
> On Mon, Jan 23, 2017 at 06:27:29AM -0500, Marc-André Lureau wrote:
> > ----- Original Message -----
> > > On Wed, Jan 18, 2017 at 08:03:07PM +0400, Marc-André Lureau wrote:
> > > > Hi,
> > >
> > > CCing Jeff Cody and John Snow, who have been working on generalizing
> > > Block Job APIs to generic background jobs. There is some overlap
> > > between async commands and background jobs.
> >
> > If you say so :) Did I miss a proposal or a discussion for async qmp
> > commands?
>
> There is no recent mailing list thread, so it's probably best to discuss
> here:
>
> The goal of jobs is to support long-running operations that can be
> managed via QMP. Jobs can have a more elaborate lifecycle than just
> start -> finish/cancel (e.g. they can be paused/resumed and may have
> multiple phases of execution that the client controls). There are QMP
> APIs to query their state (Are they running? How much "progress" has
> been made?).
Indeed, I mention that in my cover. Such use cases require something more
complete than simple async qmp commands. I don't see why it would be
incompatible with the usage of async qmp commands.
> A client reconnecting to QEMU can query running jobs. This way a client
> can resume with a running QEMU process. For commands like saving a
> screenshot is mostly does not matter, but for commands that modify state
> it's critical that clients are aware of running commands after reconnect
> to prevent corruption/interference. This behavior is what I asked about
> in my previous mail.
That's what I mention in the cover, some commands are global (and broadcasted
events are appropriate) and some are local to the client context. Some could be
discarded when the client disconnects etc. It's a case by case.
> Jobs are currently only used by the block layer and called "block jobs",
> but the idea is to generalize this. They use synchronous QMP + events.
That pattern will have the flaws I mentioned (empty return, broadcast events,
id conflict, qapi semantic & documentation etc). Something new can be invented,
but it will likely make the protocol more complicated compared to the solution
I proposed (which is optional btw, and gracefully fallbacks to sync processing
for clients that do not support the async qmp capability). However, I believe
the job interface could be built on top of what I propose.
> Jobs are more heavy-weight than async QMP commands, but pause/resume,
> rate-limiting, progress reporting, robust reconnect, etc are important
> features. Users want to be aware of long-running operations and have
> the ability to control them.
You can't generalize such job interface to all async commands. Some may not
implement the ability to report progress, to cancel, to pause etc, etc. In the
end, it will be complicated and unneeded in many cases (what's the use case to
pause or to get the progress of a screendump?). What I propose is simpler and
compatible with job/task interfaces appropriate for various domains.
> I suspect that if we transition synchronous QMP commands to async we'll
> soon have requirements for progress reporting, pause/resume, etc. So is
> there a set of commands that should be async and others that should be
> jobs or should everything just be a job?
Hard to say without a concrete proposal of what "job" is. Likely, everything is
not going to be a "job".
But hopefully qmp-async and jobs can co-exist and benefit from each other.
- Re: [Qemu-devel] [PATCH v2 23/25] console: make screendump async, (continued)
[Qemu-devel] [PATCH v2 24/25] qtest: add /qemu-qmp/screendump test, Marc-André Lureau, 2017/01/18
[Qemu-devel] [PATCH v2 25/25] qmp: move json-message-parser and check to QmpClient, Marc-André Lureau, 2017/01/18
Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type, no-reply, 2017/01/18
Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type, Stefan Hajnoczi, 2017/01/23
- Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type, Marc-André Lureau, 2017/01/23
- Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type, Stefan Hajnoczi, 2017/01/24
- Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type,
Marc-André Lureau <=
- Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type, Stefan Hajnoczi, 2017/01/30
- Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type, Marc-André Lureau, 2017/01/30
- Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type, Gerd Hoffmann, 2017/01/31
- Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type, Markus Armbruster, 2017/01/31
Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type, Markus Armbruster, 2017/01/25