Re: [Engine-devel] RFE: Actions on tasks (jobs)
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" 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, 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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] RFE: Actions on tasks (jobs)
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" 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, 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. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] RFE: Actions on tasks (jobs)
On Monday 21 January 2013 08:49 PM, Moti Asayag wrote: On 01/21/2013 02:08 PM, Shireesh Anjal wrote: 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 Could you explain what is the meaning of 'commit' in this context? The "replace brick" task in gluster migrates all data from an existing brick to the new brick which is replacing it. After all the data is migrated, user needs to perform a "commit" for the new brick to come into effect. http://gluster.org/community/documentation/index.php/Gluster_3.1:_Migrating_Volumes In addition, is there a need for a 'restart' action ? At present, we don't need such an action as far as gluster is concerned. Generally, a command (user-action / internal action) is mapped to a Job when it's monitored. The job may contain several steps where each step might represent an async-task (i.e task running on a node, vdsm task). There are two levels of control: controlling a specific vdsm task/step or controlling the entire job. I think that the granularity of the action should be on Job level, since a step's result (assuming cancelled step is considered failed) will determine the job's status as failed/aborted - therefore the rest of running steps should also be aborted. +1 If needed, supporting 'restart' operation could also be relatively easily support for job level (requires saving the action's parameters for a re-run). The Jobs cleanup manager should take care of cleaning cancelled jobs and to keep paused jobs. Does the suggested actions supported by the AsyncTaskManager and by VDSM ? No. These are not vdsm tasks. They'll be managed completely by glusterfs. We plan to introduce gluster specific verbs in vdsm for starting/managing/monitoring these tasks. http://gerrit.ovirt.org/10200 And then have a background periodic job in engine to fetch and update the status of the same in the Job repository. 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. 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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] RFE: Actions on tasks (jobs)
On Monday 21 January 2013 05:47 PM, Yair Zaslavsky wrote: - Original Message - From: "Shireesh Anjal" 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, 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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] RFE: Actions on tasks (jobs)
On 01/21/2013 02:08 PM, Shireesh Anjal wrote: > 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 Could you explain what is the meaning of 'commit' in this context? In addition, is there a need for a 'restart' action ? Generally, a command (user-action / internal action) is mapped to a Job when it's monitored. The job may contain several steps where each step might represent an async-task (i.e task running on a node, vdsm task). There are two levels of control: controlling a specific vdsm task/step or controlling the entire job. I think that the granularity of the action should be on Job level, since a step's result (assuming cancelled step is considered failed) will determine the job's status as failed/aborted - therefore the rest of running steps should also be aborted. If needed, supporting 'restart' operation could also be relatively easily support for job level (requires saving the action's parameters for a re-run). The Jobs cleanup manager should take care of cleaning cancelled jobs and to keep paused jobs. Does the suggested actions supported by the AsyncTaskManager and by VDSM ? > > 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. > > 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
Re: [Engine-devel] RFE: Actions on tasks (jobs)
- Original Message - > From: "Shireesh Anjal" > 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? 2. You mentioned task type - does this mean extending the AsyncTaskType enum? Are you going to have your own Tasks enum? > 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
[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. Thanks, Shireesh ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
