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.