[Engine-devel] [vdsm] RFD: NEW API getAllTasks

Doron Fediuck dfediuck at redhat.com
Tue May 8 07:50:49 UTC 2012


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?

- 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."



More information about the Engine-devel mailing list