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

[Shireesh Anjal]

On Tuesday 22 January 2013 08:12 PM, Itamar Heim wrote:
> 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 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.
>
> 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.

My vote is for "single entity declared as the one relevant for 
permission checks". I guess it would cover most scenarios - it 
definitely does for the gluster use case.

>
>>
>>> 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.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel