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. _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel