[ovirt-devel] short recap of last vdsm call (15.4.2014)

[Dan Kenigsberg]

On Wed, Apr 30, 2014 at 04:37:22PM +0300, ybronhei wrote:
> On 04/30/2014 04:22 PM, Dan Kenigsberg wrote:
> >On Tue, Apr 22, 2014 at 02:54:29PM +0300, ybronhei wrote:
> >>hey,
> >>
> >>somehow we missed the summary of this call, and few "big" issues
> >>were raised there. so i would like to share it with all and hear
> >>more comments
> >>
> >>- task id in http header - allows engine to initiate calls with id
> >>instead of following vdsm response - federico already started this
> >>work, and this is mandatory for live merge feature afaiu.
> >
> >Adam, Federico, may I revisit this question from another angle?
> >
> >Why does Vdsm needs to know live-merge's task id?
> >As far as I understand, (vmid, disk id) are enough to identify a live
> >merge process.
> >
> >If we do not have a task id, we do not need to worry on how to pass it,
> >and where to persist it.
> >
> engine must polls somehow the process (/task) status to know when to
> end the action (with success or fail) and release locks

Sure - but I understood that Vdsm is to report (in getAllVmStats or
whereever) the list of all pending block jobs.

We could revive the plan for a new task framework in Vdsm - if we
can convince Saggi that it would not be abused to do intractable
synchronization attempts as the current framework is. But this requires
some design and thinking - last time we did not get into an agreement
regarding the persistence semantics of tasks on Vdsm side.

Dan.