This is a multi-part message in MIME format. --------------060200060105000303080109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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_...
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
--------------060200060105000303080109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On Monday 21 January 2013 08:49 PM, Moti Asayag wrote:<br> </div> <blockquote cite="mid:50FD5C74.1020301@redhat.com" type="cite"> <pre wrap="">On 01/21/2013 02:08 PM, Shireesh Anjal wrote: </pre> <blockquote type="cite"> <pre wrap="">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 </pre> </blockquote> <pre wrap=""> Could you explain what is the meaning of 'commit' in this context?</pre> </blockquote> <br> 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.<br> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <a href="http://gluster.org/community/documentation/index.php/Gluster_3.1:_Migrating_Volumes">http://gluster.org/community/documentation/index.php/Gluster_3.1:_Migrating_Volumes</a><br> <br> <blockquote cite="mid:50FD5C74.1020301@redhat.com" type="cite"> <pre wrap="">In addition, is there a need for a 'restart' action ?</pre> </blockquote> <br> At present, we don't need such an action as far as gluster is concerned.<br> <br> <blockquote cite="mid:50FD5C74.1020301@redhat.com" type="cite"> <pre wrap="">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.</pre> </blockquote> <br> +1<br> <br> <blockquote cite="mid:50FD5C74.1020301@redhat.com" type="cite"> <pre wrap="">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 ?</pre> </blockquote> <br> 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. <a class="moz-txt-link-freetext" href="http://gerrit.ovirt.org/10200">http://gerrit.ovirt.org/10200</a><br> <br> And then have a background periodic job in engine to fetch and update the status of the same in the Job repository.<br> <br> <blockquote cite="mid:50FD5C74.1020301@redhat.com" type="cite"><br> <blockquote type="cite"> <pre wrap="">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 <a class="moz-txt-link-abbreviated" href="mailto:Engine-devel@ovirt.org">Engine-devel@ovirt.org</a> <a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/engine-devel">http://lists.ovirt.org/mailman/listinfo/engine-devel</a> </pre> </blockquote> <pre wrap=""> _______________________________________________ Engine-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Engine-devel@ovirt.org">Engine-devel@ovirt.org</a> <a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/engine-devel">http://lists.ovirt.org/mailman/listinfo/engine-devel</a> </pre> </blockquote> <br> </body> </html> --------------060200060105000303080109--