On Tue, May 08, 2012 at 10:50:49AM +0300, Doron Fediuck wrote:
On 07/05/12 21:33, Adam Litke wrote:
> The current APIs for retrieving all task information do not actually return all
> task information. I would like to introduce a new API that corrects this and
> other issues with the current API while preserving backwards compatibility with
> ovirt-engine for as long as is necessary.
>
> The current APIs:
>
> getAllTasksInfo(spUUID=None, options = None):
> - Returns a dictionary that maps a task UUID to a task verb.
> - Despite having 'all' in the name, this API only returns tasks that have
an
> 'spm' tag.
> - This call returns only one piece of information for each task.
> - The spUUID parameter is deprecated and ignored.
>
> getAllTasksStatuses(spUUID=None, options = None):
> - Returns a dictionary of task status information.
> - Despite having 'all' in the name, this API only returns tasks that have
an
> 'spm' tag.
> - The spUUID parameter is deprecated and ignored.
>
>
> I propose the following new API:
>
> getAllTasks(tag=None, options=None):
> - Returns a dictionary of task information. The info from both of the above
> functions would be merged into a single result set.
> - If tag is None, all tasks are returned. otherwise, only tasks matching the
> tag are returned.
> - The spUUID parameter is dropped. options is for future extension and is
> currently not used.
>
> This new API includes all functionality that is available in the old calls. In
> the future, ovirt-engine could switch to this API and preserve the current
> semantics by passing tag='spm' to getAllTasks. Meanwhile, API users that
really
> want all tasks (gluster and the REST API) can get what they need.
>
> Thoughts on this idea?
>
(Adding engine-devel, as this relates to the engine API).
AFAIR, in the original design (when a-sync tasks where introduced into vdsm),
most (if not all) of the tasks were SPM tasks, and this is the reason for this
behavior.
Improving the API is welcomed. The suggested design should work.
I'd like to verify:
- Backwards compatibility works; so running engine's shouldn't be replaced.
Dan: any news on this?
Yes, we should make sure that future versions of ovirt-engine that would want to
adopt this new API will have the behavior that they will need. For now, I plan
to keep around the current/original APIs until they can be removed as part of a
deprication plan in a few years.
- Going forward with potential changes in SPM concepts should be
supported as well.
Dan/Ayal/Livnat: do you think it works? ie- anything else needed than alternate
'spm' tag?
--
/d
"All computers wait at the same speed."
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center