----- Original Message -----
> 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?

So every plugin into vdsm would now expose tasks through this API and every app 
using getAllTasks would see the full list?
a. I'm not sure we can require all plugins to comply
b. I'm not sure default should return all tasks for all plugins, maybe just for 
vdsm native.
To get gLuster tasks one would then need to specify gLuster in the tag.
Either way, I suggest that tag would support a list so that if I'm interested 
in a subset I would be able to specify that (perhaps 'tag' is the wrong name 
for that though)
What do you think?

> 
> --
> Adam Litke <a...@us.ibm.com>
> IBM Linux Technology Center
> 
> 
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to