[openstack-dev] [Mistral] Proposal for the Resume Feature

Dmitri Zimine dzimine at stackstorm.com
Tue Mar 31 02:56:39 UTC 2015


Thanks Winson for the summary. 

@Lingxian Kong
>  The context for a task is used
> internally, I know the aim for this feature is to make it very easy
> and convinient for users to see the details for the workflow exection,
> but what users can do next with the context? Do you have a plan to
> change that context for a task by users? if the answer is no, I think
> it is not very necessary to expose the context endpoint.

I think the answer is “yes users will change the context” this falls out of use case #3. 
Let’s be specific: a create_vm task failed due to, say, network connection. 
As a user, I created the VM manually, now want to continue the workflow. 
Next step is attach storage to VM, needs VM ID published variable. So a user needs to 
modify outgoing context of create_vm task.

May be use case 2 be sufficient? 
We are also likely to specify multiple tasks: in case a parallel execution of two tasks
(create VM, create DNS record) failed again due to network conditions - than network 
is back I want to continue, but re-run those two exact tasks. 

Another point, may be obvious but let’s articulate it: we re-run task, not individual action within task.
In context of with_items, retry, repeat, it will lead to running actions multiple times.

Finally, workflow execution traceability. We need to get to the point of tracing pause and resume as workflow events. 

@Lingxian Kong
>  we can introduce the notification
> system to Mistral, which is heavily used in other OpenStack projects.
care to elaborare? Thanks! 

DZ>  


On Mar 26, 2015, at 10:29 PM, Lingxian Kong <anlin.kong at gmail.com> wrote:

> On Fri, Mar 27, 2015 at 11:20 AM, W Chan <m4d.coder at gmail.com> wrote:
>> We assume WF is in paused/errored state when 1) user manually pause the WF,
>> 2) pause is specified on transition (on-condition(s) such as on-error), and
>> 3) task errored.
>> 
>> The resume feature will support the following use cases.
>> 1) User resumes WF from manual pause.
>> 2) In the case of task failure, user fixed the problem manually outside of
>> Mistral, and user wants to re-run the failed task.
>> 3) In the case of task failure, user fixed the problem manually outside of
>> Mistral, and user wants to resume from the next task.
> this use case does really make sense to me.
>> 
>> Resuming from #1 should be straightforward.
>> Resuming from #2, user may want to change the inbound context.
>> Resuming from #3, users is required to manually provide the published vars
>> for the failed task(s).
>> 
>> In our offline discussion, there's ambiguity with on-error clause and
>> whether a task failure has already been addressed by the WF itself.  In many
>> cases, the on-error tasks may just be logging, email notification, and/or
>> other non-recovery procedures.  It's hard to determine that automatically,
>> so we let users decide where to resume the WF instead.  Mistral will let
>> user resume a WF from specific point. The resume function will determine the
>> requirements needed to successfully resume.  If requirements are not met,
>> then resume returns an error saying what requirements are missing.  In the
>> case where there are failures in multiple parallel branches, the
>> requirements may include more than one tasks.  For cases where user
>> accidentally resume from an earlier task that is already successfully
>> completed, the resume function should detect that and throw an exception.
>> 
>> Also, the current change to separate task from action execution should be
>> sufficient for traceability.
>> 
>> We also want to expose an endpoint to let users view context for a task.
>> This is to let user have a reference of the current task context to
>> determine the delta they need to change for a successful resume.
> IMHO, I'm afraid I can't agree here. The context for a task is used
> internally, I know the aim for this feature is to make it very easy
> and convinient for users to see the details for the workflow exection,
> but what users can do next with the context? Do you have a plan to
> change that context for a task by users? if the answer is no, I think
> it is not very necessary to expose the context endpoint.
> 
> However, considering the importance of context for the task
> execution(the resuming feature), we can introduce the notification
> system to Mistral, which is heavily used in other OpenStack projects.
>> 
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> 
> 
> -- 
> Regards!
> -----------------------------------
> Lingxian Kong
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150330/1d545ec1/attachment.html>


More information about the OpenStack-dev mailing list