Am 02.02.23 um 12:34 schrieb Kevin Wolf:
Am 02.02.2023 um 11:19 hat Fiona Ebner geschrieben:
Am 31.01.23 um 19:18 schrieb Denis V. Lunev:
Frankly speaking I would say that this switch could be considered
NOT QEMU job and we should just send a notification (event) for the
completion of the each iteration and management software should
take a decision to switch from async mode to the sync one.
My first thought was very similar. We should provide a building block
that just switches between the two modes and then the management tool
can decide what the right policy is.
Adding a new event when the first iteration is done (I'm not sure if
there is much value in having it for later iterations) makes sense to
me if someone wants to use it. If we add it, let's not forget that
events can be lost and clients must be able to query the same
information, so we'd have to add it to query-jobs, too - which in turn
requires adding a job type specific struct to JobInfo first.
Well, Denis said 2 iterations might be better. But I'm fine with
initially adding an event just for the first iteration, further ones can
still be added later. Returning the number of completed iterations as
part of the mirror-specific job info would anticipate that.