On 11.03.24 00:07, Peter Krempa wrote:
On Thu, Mar 07, 2024 at 22:42:56 +0300, Vladimir Sementsov-Ogievskiy wrote:
On 04.03.24 14:09, Peter Krempa wrote:
On Mon, Mar 04, 2024 at 11:48:54 +0100, Kevin Wolf wrote:
Am 28.02.2024 um 19:07 hat Vladimir Sementsov-Ogievskiy geschrieben:
On 03.11.23 18:56, Markus Armbruster wrote:
Kevin Wolf<kw...@redhat.com> writes:
[...]
I only see the following differencies:
1. block-job-complete documents that it completes the job synchronously.. But
looking at mirror code I see it just set s->should_complete = true, which will
be then handled asynchronously.. So I doubt that documentation is correct.
2. block-job-complete will trigger final graph changes. block-job-cancel will
not.
Is [2] really useful? Seems yes: in case of some failure before starting
migration target, we'd like to continue executing source. So, no reason to
break block-graph in source, better keep it unchanged.
But I think, such behavior better be setup by mirror-job start parameter,
rather then by special option for cancel (or even compelete) command, useful
only for mirror.
Libvirt's API design was based on the qemu quirk and thus we allow users
to do the decision after starting the job, thus anything you pick needs
to allow us to do this at "completion" time.
OK, this means that simply switch to an option at job-start is not enough.
Libvirt can adapt to any option that will give us the above semantics
(extra parameter at completion time, different completion command or
extra command to switch job properties right before completion), but to
be honest all of these feel like they would be more hassle than keeping
'block-job-cancel' around from qemu's side.
I understand. But still, it would be good to finally resolve the duplication
between job-* and block-job-* APIs. We can keep old quirk working for a long
time even after making a new consistent API.
--
Best regards,
Vladimir
