On Fri, May 25, 2018 at 10:00:35AM +0200, Kevin Wolf wrote:
> Am 24.05.2018 um 19:42 hat John Snow geschrieben:
[...]
(Randomly chiming in for a small clarification.)
> > >> or some other mechanism that accomplishes the same type of behavior. It
> > >> would be nice if it did not have to be determined at job creation time
> > >> but instead could be determined later.
> > >
> > > I agree. We already made sure that job-cancel really means cancel on the
> > > QAPI level, so we're free to do that. We just need to keep supporting
> > > block-job-cancel with the old semantics, so what I have is the easy
> > > conversion. We can change the internal implementation when we actually
> > > implement the selection of a completion mode.
> > >
> > > Kevin
> > >
> >
> > We need this before 3.0 though, yeah? unless we make job-cancel
> > x-job-cancel or some other warning that the way it works might change, yeah?
> >
> > Or do I misunderstand our leeway to change this at a later point in time?
> >
> > (can job-cancel apply to block jobs created with the legacy
> > infrastructure? My reading was "yes.")
>
> It can, and it already has its final semantics, so nothing has to change
> before 3.0. job-cancel is equivalent to block-job-cancel with fixed
> force=true. If you want the complete-by-cancel behaviour of mirror, you
> have to use block-job-cancel for now, because job-cancel doesn't provide
> that functionality.
I think by "complete-by-cancel" you are referring to this[*] magic
behaviour, mentioned in the last sentence here:
When you cancel an in-progress ‘mirror’ job before the source and
target are synchronized, block-job-cancel will emit the event
BLOCK_JOB_CANCELLED. However, note that if you cancel a ‘mirror’ job
after it has indicated (via the event BLOCK_JOB_READY) that the
source and target have reached synchronization, then the event
emitted by block-job-cancel changes to BLOCK_JOB_COMPLETED.
[*]
https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/live-block-operations.rst#l515
> So what we can change later is adding a way to initiate this secondary
> completion mode with a job-* command (probably with a new option for
> job-complete). But we wouldn't change the semantics of exisiting
> commands.
Ah, so if I'm understanding it correctly, the existing subtle magic of
"complete-by-cancel" will be rectified by separting the two distinct
operations: 'job-cancel' and 'job-complete'.
--
/kashyap
