On 05/14/2012 06:20 PM, Adam Litke wrote:
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
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 :)

FYI gluster support in vdsm will be a plugin. If vdsm-gluster is installed, then gluster tasks will be available through getAllTasks and this verb will be dynamic in those cases.

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!

vdsm-devel mailing list

Reply via email to