7:10 a.m.
Hi guys,
Thanks for all your comments!
The correct response for many these points is to update the wiki.
I'm enclosing here the quick-and-dirty replies just to keep this thread alive, and
will update the wiki shortly.
See inline.
----- Original Message -----
From: "Livnat Peer" <lpeer(a)redhat.com>
To: "Allon Mureinik" <amureini(a)redhat.com>
Cc: "Eli Mesika" <emesika(a)redhat.com>, "Liron Aravot"
<laravot(a)redhat.com>, "Federico Simoncelli"
<fsimonce(a)redhat.com>, "engine-devel" <engine-devel(a)ovirt.org>,
"Eduardo Warszawski" <ewarszaw(a)redhat.com>, "Yeela
Kaplan" <ykaplan(a)redhat.com>
Sent: Sunday, August 12, 2012 9:39:23 AM
Subject: Re: [Engine-devel] Serial Execution of Async Tasks
On 10/08/12 03:40, Eli Mesika wrote:
>
>
> ----- Original Message -----
>> From: "Allon Mureinik" <amureini(a)redhat.com>
>> To: "engine-devel" <engine-devel(a)ovirt.org>
>> Cc: "Eduardo Warszawski" <ewarszaw(a)redhat.com>, "Yeela
Kaplan"
>> <ykaplan(a)redhat.com>, "Federico Simoncelli"
>> <fsimonce(a)redhat.com>, "Liron Aravot"
<laravot(a)redhat.com>
>> Sent: Thursday, August 9, 2012 6:41:09 PM
>> Subject: [Engine-devel] Serial Execution of Async Tasks
>>
>> Hi guys,
>>
>> As you may know the engine currently has the ability to fire an
>> SPM
>> task, and be asynchronously be "woken-up" when it ends.
>> This is great, but we found the for the Live Storage Migration
>> feature we need something a bit complex - the ability to have a
>> series of async tasks in a single control flow.
>>
>> Here's my initial design for this, your comments and criticism
>> would
>> be welcome:
>>
http://wiki.ovirt.org/wiki/Features/Serial_Execution_of_Asynchronous_Task...
>
> Apart from the short explanation & flow , since this is a detailed
> design , I would add
> 1) Class diagram
> 2) Flow diagram
Good idea, I'll see if I can jimmy something up.
>
+1, it would help understanding the flow.
- It looks like you chose not re-use/extend the ExecutionHandler (the
entity used for building the tasks view exposed to the users).
It might be a good idea to keep the separation between the engine
Jobs
and the underlying vdsm tasks, but I want to make sure you are
familiar
with this mechanism and ruled it out with a reason. If this is the
case
please share why you decided not to use it.
As you said Jobs and Steps are pure
engine entities - they can contain no VDSM tasks, one VDSM task, or plausibly, in the
future, several tasks.
Even /today/, AsyncTasks and Jobs/Steps are two different kinds of animals - I don't
see any added value in mixing them together.
- how does this design survives a jboss restart? Can you please a
section in the wiki to explain that.
Basically, the way as a Command does today -
the task is saved with the executionIndex, and continues when the command is woken up.
I'll clarify this point in the wiki.
-successful execution -
* "CommandBase iterates over its SPMAsyncTaskHandlers" - when?
This is
the new suggested format of executeCommand(). I'll clarify this too.
* If the second task is an HSM command (vs. SPM command), I think
you
should explain in the design how to handle such flows as well.
HSM commands do not
create AsyncTasks, as they do today - I will clarify this.
* Why do we need before task? can you give a concrete example of
what
would you do in such a method.
Basically, /today/, command look like this:
executeCommand() {
doStuffInTheDB();
runVdsCommand(someCommand);
}
endSuccessfully() {
doMoreStuffInTheDB();
}
endWithFailure() {
doMoreStuffForFailureInTheDB();
}
In the new design, the entire doStuffInTheDB() should be moved to a breforeTask of the
(only) SPMAsyncTaskHandler.
- I see you added SPMAsyncTaskHandler, any reason not to use
SPMAsyncTasK to manage it own life-cycle?
Conserving today's design - The
SPMAsyncTaskHandler is the place to add additional, non-SPM, logic around the SPM task
execution, like CommandBase allows today.
- In the life-cycle managed by the SPMAsyncTaskHandler there is a
step
'createTask - how to create the async task' can you please elaborate
what are the options.
new [any type of async task]
Livnat
>>
>>
>> -Allon
>> _______________________________________________
>> 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
>