----- Original Message -----
> From: "Adam Litke" <a...@us.ibm.com>
> To: vdsm-devel@lists.fedorahosted.org
> Cc: "Dan Kenigsberg" <dan...@redhat.com>, "Ayal Baron" <aba...@redhat.com>, 
> "Saggi Mizrahi" <smizr...@redhat.com>,
> "Federico Simoncelli" <fsimo...@redhat.com>, engine-de...@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 <a...@us.ibm.com>
> IBM Linux Technology Center
vdsm-devel mailing list

Reply via email to