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