----- Original Message -----
From: "Adam Litke" <agl(a)us.ibm.com>
To: vdsm-devel(a)lists.fedorahosted.org
Cc: "Dan Kenigsberg" <danken(a)redhat.com>, "Ayal Baron"
<abaron(a)redhat.com>, "Saggi Mizrahi" <smizrahi(a)redhat.com>,
"Federico Simoncelli" <fsimonce(a)redhat.com>, engine-devel(a)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(a)us.ibm.com>
IBM Linux Technology Center