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