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