22 Jan
2013
22 Jan
'13
1:18 p.m.
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. > 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@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel