----- Original Message -----
> From: "Adam Litke" <a...@us.ibm.com>
> To: firstname.lastname@example.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
> 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
> 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
> - 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
> 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