[Engine-devel] RFE: Actions on tasks (jobs)

[Shireesh Anjal]

On Monday 21 January 2013 05:47 PM, Yair Zaslavsky wrote:
>
> ----- Original Message -----
>> From: "Shireesh Anjal" <sanjal at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Monday, January 21, 2013 2:08:14 PM
>> Subject: [Engine-devel] RFE: Actions on tasks (jobs)
>>
>> Hi,
>>
>> We plan to introduce support for gluster tasks in oVirt, using the
>> current Jobs/steps framework. Which means, any gluster async task
>> started on a cluster will be shown as a Job in the "Tasks" tab. While
>> this helps in listing and monitoring the status of all gluster tasks,
>> we
>> have a requirement to support a set of actions on such tasks. One
>> should
>> be able to select a task, and then, if supported for that task,
>> perform
>> one or more of the following actions on it:
>>
>> - pause
>> - resume
>> - abort
>> - commit
>>
>> I think this can probably be achieved by introducing a generic
>> mechanism
>> for performing actions on task, allowing each type of task to define
>> what actions are allowed on it in it's current state.
>>
>> Requesting opinions/suggestions on possible ways to achieve this
>> requirement.
> Several points -
> 1. By performing actions - you probably mean the entry point to engine will be BllCommand? StopTaskCommand for example?
> If so, we need to think about the permission of the command. who can stop a for example? What is its role?

I see that Job extends BusinessEntity<Guid>, and hence should be 
possible to assign permissions on it, just like any other entity? Though 
I think this doesn't fit directly in the current UI, as jobs is not a 
main tab. In case of gluster, I would add this permission to the 
'GlusterAdmin' role.

> 2. You mentioned task type - does this mean extending the AsyncTaskType enum? Are you going to have your own Tasks enum?

I'm not sure about AsyncTaskType, as I believe it is related to the vdsm 
async tasks and AsyncTaskManager, and I don't think we'll be going there.

In our case, the command being executed in the job itself could be 
synonymous to the task type. What I mean by task type specific actions 
is, not all actions are applicable on all types of tasks. e.g. "commit" 
is applicable only to a "replace brick" task, and not to "rebalance 
volume" task, whereas "abort" is applicable to both. So the 
corresponding command should dictate what action can be performed on the 
task.

>   
>> Thanks,
>> Shireesh
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel