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 <[email protected]> wrote: > On Fri, Mar 27, 2015 at 11:20 AM, W Chan <[email protected]> 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: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Regards! > ----------------------------------- > Lingxian Kong > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
