5:08 a.m.
Hi all,
I would like to present you a document I'm working on (still in
draft/working-in-progress mode) of changes to be done at the engine async task manager.
Regarding the detailed design -
The suggested design breaks the task management into two modules - task management/polling
part + command management (in context of completion of tasks/commands).
The current status of the design is that the design of task management is provided (needs
some polishing) - the command management design will be provided soon.
In addition, we already have some ideas for an alternative design for the task management
part (as suggested by Saggi Mizrahi).
After converging , we will present the complete design.
The reason we're sending the Wiki now is that community members will be aware mainly
to the motivations behind the changes
(Perhaps we should create separate documents for the design and for the
motivation/requirements)
http://www.ovirt.org/Wiki/AsyncTaskManagerChanges
Yair
12:53 a.m.
Hi Yair,
Thanks for the detailed design.
Had some questions
1. Can we think about introducing some DI framework in the Task
Management package. This could be used to inject the DAL, VDS Broker,
Commons etc dependencies. Even the list of providers and TaskStatusEvent
handlers could be registered using this framework.
2. You mention "Several providers that refer to instances of the same
external system type have the same ProviderLogic object. " I'm not sure
I understand this. Could you clarify?
3. Will TaskManager also talk to Job entity and update/end Job if necessary?
4. Are we planning to support custom actions on tasks? That is,
depending on status of task, task can be paused/ resumed/ aborted
/custom action performed etc
thanks
sahina
On 03/11/2013 03:38 PM, Yair Zaslavsky wrote:
Hi all,
I would like to present you a document I'm working on (still in
draft/working-in-progress mode) of changes to be done at the engine async task manager.
Regarding the detailed design -
The suggested design breaks the task management into two modules - task
management/polling part + command management (in context of completion of
tasks/commands).
The current status of the design is that the design of task management is provided (needs
some polishing) - the command management design will be provided soon.
In addition, we already have some ideas for an alternative design for the task management
part (as suggested by Saggi Mizrahi).
After converging , we will present the complete design.
The reason we're sending the Wiki now is that community members will be aware mainly
to the motivations behind the changes
(Perhaps we should create separate documents for the design and for the
motivation/requirements)
http://www.ovirt.org/Wiki/AsyncTaskManagerChanges
Yair
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
1:01 a.m.
----- Original Message -----
From: "Sahina Bose" <sabose(a)redhat.com>
To: engine-devel(a)ovirt.org
Sent: Thursday, March 14, 2013 7:53:15 AM
Subject: Re: [Engine-devel] Async Task Manager improvements
Hi Yair,
Thanks for the detailed design.
Hi Sahina, we're going to change the detailed design, to be more flexible and loose
coupled.
Had some questions
1. Can we think about introducing some DI framework in the Task
Management package. This could be used to inject the DAL, VDS Broker,
Commons etc dependencies. Even the list of providers and
TaskStatusEvent
handlers could be registered using this framework.
I think that at this point it's too early to talk about DI at the new task mgmt
framework, but that's a possibility.
We're aiming to a more general framework for scheduling operations + providing a
mechanism to signal objects when the operations are ended.
2. You mention "Several providers that refer to instances of the same
external system type have the same ProviderLogic object. " I'm not
sure
I understand this. Could you clarify?
This is still a draft and may change. I wanted to distinguish for example between an
instance of SPM or gluster host and the logic to handle their task-related issues - so,
you may have several instances of "task provider", but you have one logic per
task provider type.
3. Will TaskManager also talk to Job entity and update/end Job if
necessary?
Yes, this was not addressed at this point.
4. Are we planning to support custom actions on tasks? That is,
depending on status of task, task can be paused/ resumed/ aborted
/custom action performed etc
Yes, the next phase of the design we're working on will be more flexible, and you will
be able to have more flexibility.
thanks
sahina
On 03/11/2013 03:38 PM, Yair Zaslavsky wrote:
> Hi all,
>
> I would like to present you a document I'm working on (still in
> draft/working-in-progress mode) of changes to be done at the
> engine async task manager.
>
> Regarding the detailed design -
>
> The suggested design breaks the task management into two modules -
> task management/polling part + command management (in context of
> completion of tasks/commands).
> The current status of the design is that the design of task
> management is provided (needs some polishing) - the command
> management design will be provided soon.
>
> In addition, we already have some ideas for an alternative design
> for the task management part (as suggested by Saggi Mizrahi).
> After converging , we will present the complete design.
> The reason we're sending the Wiki now is that community members
> will be aware mainly to the motivations behind the changes
>
> (Perhaps we should create separate documents for the design and for
> the motivation/requirements)
>
> http://www.ovirt.org/Wiki/AsyncTaskManagerChanges
>
>
> Yair
>
>
> _______________________________________________
> 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
4060
days inactive
4063
days old
2 comments
2 participants
participants (2)
-
Sahina Bose -
Yair Zaslavsky