22 Jan
2013
22 Jan
'13
1:53 p.m.
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@redhat.com> >>>> To: engine-devel@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@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel