Re: [ovirt-devel] short recap of last vdsm call (15.4.2014)
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.