From sanjal at redhat.com Tue Jan 22 09:28:47 2013 Content-Type: multipart/mixed; boundary="===============2274094884898901697==" MIME-Version: 1.0 From: Shireesh Anjal To: devel at ovirt.org Subject: Re: [Engine-devel] RFE: Actions on tasks (jobs) Date: Tue, 22 Jan 2013 19:58:40 +0530 Message-ID: <50FEA218.5060608@redhat.com> In-Reply-To: 50FD5C74.1020301@redhat.com --===============2274094884898901697== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------060200060105000303080109 Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed 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= _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(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel --------------060200060105000303080109 Content-Type: text/html; charset=3DISO-8859-1 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/Glus= ter_3.1:_Migrating_Volumes

In addition, is there a need for a 'restart' action ?<=
/pre>

At present, we don't need such an action as far as gluster is concerned.

Generally, a command (user-action / internal action) i=
s 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 b=
e 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>

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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel<=
/a>

_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel<=
/a>