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" <[email protected]>
To: [email protected]
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
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
