[Engine-devel] Managing async tasks
Saggi Mizrahi
smizrahi at redhat.com
Mon Dec 17 17:15:08 UTC 2012
----- Original Message -----
> From: "Adam Litke" <agl at us.ibm.com>
> To: vdsm-devel at lists.fedorahosted.org
> Cc: "Dan Kenigsberg" <danken at redhat.com>, "Ayal Baron" <abaron at redhat.com>, "Saggi Mizrahi" <smizrahi at redhat.com>,
> "Federico Simoncelli" <fsimonce at redhat.com>, engine-devel at ovirt.org
> Sent: Monday, December 17, 2012 12:00:49 PM
> Subject: Managing async tasks
>
> On today's vdsm call we had a lively discussion around how
> asynchronous
> operations should be handled in the future. In an effort to include
> more people
> in the discussion and to better capture the resulting conversation I
> would like
> to continue that discussion here on the mailing list.
>
> A lot of ideas were thrown around about how 'tasks' should be handled
> in the
> future. There are a lot of ways that it can be done. To determine
> how we
> should implement it, it's probably best if we start with a set of
> requirements.
> If we can first agree on these, it should be easy to find a solution
> that meets
> them. I'll take a stab at identifying a first set of POSSIBLE
> requirements:
>
> - Standardized method for determining the result of an operation
>
> This is a big one for me because it directly affects the
> consumability of the
> API. If each verb has different semantics for discovering whether
> it has
> completed successfully, then the API will be nearly impossible to
> use easily.
Since there is no way to assure if of some tasks completed successfully or failed, especially around the murky waters of storage, I say this requirement should be removed.
At least not in the context of a task.
>
>
> Sorry. That's my list :) Hopefully others will be willing to add
> other
> requirements for consideration.
>
> From my understanding, task recovery (stop, abort, rollback, etc)
> will not be
> generally supported and should not be a requirement.
>
>
>
> --
> Adam Litke <agl at us.ibm.com>
> IBM Linux Technology Center
>
>
More information about the Engine-devel
mailing list