[Engine-devel] RFE: Actions on tasks (jobs)

Shireesh Anjal sanjal at redhat.com
Tue Jan 22 14:28:40 UTC 2013


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 at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130122/a8d773f0/attachment.html>


More information about the Engine-devel mailing list