Re: [Engine-devel] Serial Execution of Async Tasks

From: "Maor Lipchuk" <mlipchuk(a)redhat.com&gt; To: "Itamar Heim" <iheim(a)redhat.com&gt; Cc: "Allon Mureinik" <amureini(a)redhat.com&gt;, "engine-devel" <engine-devel(a)ovirt.org&gt;, "Eduardo Warszawski" <ewarszaw(a)redhat.com&gt;, "Yeela Kaplan" <ykaplan(a)redhat.com&gt;, "Federico Simoncelli" <fsimonce(a)redhat.com&gt;, "Liron Aravot" <laravot(a)redhat.com&gt; Sent: Thursday, August 16, 2012 8:27:33 PM Subject: Re: [Engine-devel] Serial Execution of Async Tasks On 08/16/2012 06:51 PM, Itamar Heim wrote: > 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. yes, but if I understood correctly, we don't want to correlate the multiple tasks with the execution handler (which AFAIK handle the correlation id).

I assume this issue can be addressed in a future phase, but maybe it is an issue that might worth to think about. > >>> >>>> >>>> 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(a)redhat.com&gt; >>>>>> To: "Allon Mureinik" <amureini(a)redhat.com&gt; >>>>>> Cc: "Eli Mesika" <emesika(a)redhat.com&gt;, "Liron Aravot" >>>>>> <laravot(a)redhat.com&gt;, "Federico Simoncelli" >>>>>> <fsimonce(a)redhat.com&gt;, "engine-devel" >>>>>> <engine-devel(a)ovirt.org&gt;, >>>>>> "Eduardo Warszawski" <ewarszaw(a)redhat.com&gt;, "Yeela >>>>>> Kaplan" <ykaplan(a)redhat.com&gt; >>>>>> 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&gt; >>>>>>>> To: "engine-devel" <engine-devel(a)ovirt.org&gt; >>>>>>>> Cc: "Eduardo Warszawski" <ewarszaw(a)redhat.com&gt;, "Yeela >>>>>>>> Kaplan" >>>>>>>> <ykaplan(a)redhat.com&gt;, "Federico Simoncelli" >>>>>>>> <fsimonce(a)redhat.com&gt;, "Liron Aravot" <laravot(a)redhat.com&gt; >>>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >> >> > >