Open Stack

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