8:42 a.m.
On 22/01/2013 06:18, Shireesh Anjal wrote:
On Monday 21 January 2013 05:47 PM, Yair Zaslavsky wrote:
>
> ----- Original Message -----
>> From: "Shireesh Anjal" <sanjal(a)redhat.com>
>> To: engine-devel(a)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.
jobs are transient, so permissions are probably implied/created as part
of job creation.
the tricky part is if you have two admins, one for each cluster, how do
you check for permissions on the job for the relevant actiongroup.
based on DC? cluster? volume? on all of the entities associated with the
job, on any of the entities related to the job, for each job via a
single entity declared as the one relevant for permission checks, etc.
> 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.