[Engine-devel] Serial Execution of Async Tasks

Thu Aug 16 15:51:31 UTC 2012

On 08/16/2012 03:21 PM, Maor Lipchuk wrote:
> On 08/14/2012 05:23 PM, Itamar Heim wrote:
>> On 08/14/2012 02:35 PM, Maor Lipchuk wrote:
>>> How should we handle the auditLogMessages?
>>> Basically when a command ends it print an audit log.
>>>
>>> When we will start to use multiple tasks I assume user might get a bulk
>>> of audit logs which are actually related to the same action (when we
>>> fail for example the process will be create and delete).
>>> It might be a bit confusing for the user not to know which action is
>>> related to the operation
>>
>> I thought audit log gets written regardless of the transaction, so audit
>> log appears "as they happen"?
> That is correct,
> The issue that I was referring to, is that now, with multiple tasks
> execution, we will get many audit logs which related to the same
> transaction but each one will be printed at a different time.
>
> I think that it might be confusing for the user to relate each audit log
> to the operation that was started.
>
>
> For example :
> User run an action that executes some tasks of create volumes,
> then the engine encounter a problem, and decide to rollback the
> operation and delete the volumes, in that case the engine will execute a
> delete task for the volumes, so user might see that delete of the volume
> (for example a snapshot) was initiated.
> Since those are asynchronous tasks, audit log will be printed in a
> different period of time and a user might not be aware what is the
> relation of those specific delete.

async doesn't mean we don't print an audit log when we start it, and 
when we end it.
so user would get the starting audit log when the task failed in your 
example. of course this may happen 2 hours after they started the task. 
as long as we can correlate the audit log to be part of the same "job", 
i don't see the issue.

>>
>>>
>>> Maybe we will need to use the correlation id of the Execution handler as
>>> Eli suggested or maybe add new states at CommandActionState?
>>>
>>> On 08/14/2012 02:10 PM, Allon Mureinik wrote:
>>>> 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 at redhat.com>
>>>>> To: "Allon Mureinik" <amureini at redhat.com>
>>>>> Cc: "Eli Mesika" <emesika at redhat.com>, "Liron Aravot"
>>>>> <laravot at redhat.com>, "Federico Simoncelli"
>>>>> <fsimonce at redhat.com>, "engine-devel" <engine-devel at ovirt.org>,
>>>>> "Eduardo Warszawski" <ewarszaw at redhat.com>, "Yeela
>>>>> Kaplan" <ykaplan at 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 at redhat.com>
>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
>>>>>>> Cc: "Eduardo Warszawski" <ewarszaw at redhat.com>, "Yeela Kaplan"
>>>>>>> <ykaplan at redhat.com>, "Federico Simoncelli"
>>>>>>> <fsimonce at redhat.com>, "Liron Aravot" <laravot at 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_Tasks_Detailed_Design
>>>>>>>
>>>>>>
>>>>>> 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 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
>>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>
>