6:08 a.m.
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
6:17 a.m.
----- Original Message -----
From: "Shireesh Anjal" <sanjal(a)redhat.com>
To: engine-devel(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:19 a.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
8:18 a.m.
On Monday 21 January 2013 05:47 PM, Yair Zaslavsky wrote:
----- Original Message -----
> From: "Shireesh Anjal" <sanjal(a)redhat.com>
> To: engine-devel(a)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<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.
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(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
8:28 a.m.
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:_Migrati...
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=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...
<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...
<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">...
</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">...
</pre>
</blockquote>
<br>
</body>
</html>
--------------060200060105000303080109--
8:42 a.m.
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" <sanjal(a)redhat.com>
>> To: engine-devel(a)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<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.
> 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.
8:53 a.m.
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" <sanjal(a)redhat.com>
>>> To: engine-devel(a)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<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
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
4119
days inactive
4120
days old
6 comments
4 participants
participants (4)
-
Itamar Heim -
Moti Asayag -
Shireesh Anjal -
Yair Zaslavsky