On Sat, May 12, 2012 at 05:10:31PM -0400, Ayal Baron wrote: > > > ----- 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.
I must confess I don't have any insight on what you mean by 'plugin' tasks. The only ones I am aware of are the native tasks we have today. I am explicitly trying to fix the API for native tasks but want to make sure it would be resilient against planned development. > To get gLuster tasks one would then need to specify gLuster in the tag. I disagree. All tasks should always mean all tasks. Otherwise we are simply making the same mistake as we did with this 'spm' tag thing. If you want to narrow down the list, then specify the tags :) > 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) Sure, a list of tags would be fine by me. For testing purposes, how can I manipulate the tags on tasks so that I can test such a query interface? Thanks for your comments! -- Adam Litke <a...@us.ibm.com> IBM Linux Technology Center _______________________________________________ vdsm-devel mailing list email@example.com https://fedorahosted.org/mailman/listinfo/vdsm-devel