<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Thanks Winson for the summary. <div><br></div><div>@Lingxian Kong</div><div><blockquote type="cite"> The context for a task is used<br>internally, I know the aim for this feature is to make it very easy<br>and convinient for users to see the details for the workflow exection,<br>but what users can do next with the context? Do you have a plan to<br>change that context for a task by users? if the answer is no, I think<br>it is not very necessary to expose the context endpoint.</blockquote><div><br></div>I think the answer is “yes users will change the context” this falls out of use case #3. </div><div>Let’s be specific: a create_vm task failed due to, say, network connection. </div><div>As a user, I created the VM manually, now want to continue the workflow. </div><div>Next step is attach storage to VM, needs VM ID published variable. So a user needs to </div><div>modify outgoing context of create_vm task.</div><div><br></div><div>May be use case 2 be sufficient? </div><div>We are also likely to specify multiple tasks: in case a parallel execution of two tasks</div><div>(create VM, create DNS record) failed again due to network conditions - than network </div><div>is back I want to continue, but re-run those two exact tasks. </div><div><br></div><div>Another point, may be obvious but let’s articulate it: we re-run task, not individual action within task.</div><div>In context of with_items, retry, repeat, it will lead to running actions multiple times.</div><div><br></div><div>Finally, workflow execution traceability. We need to get to the point of tracing pause and resume as workflow events. </div><div><br></div><div>@Lingxian Kong</div><div><blockquote type="cite"> we can introduce the notification<br>system to Mistral, which is heavily used in other OpenStack projects.</blockquote>care to elaborare? Thanks! </div><div><br></div><div>DZ> </div><div><br></div><div><br><div><div>On Mar 26, 2015, at 10:29 PM, Lingxian Kong <<a href="mailto:anlin.kong@gmail.com">anlin.kong@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Fri, Mar 27, 2015 at 11:20 AM, W Chan <<a href="mailto:m4d.coder@gmail.com">m4d.coder@gmail.com</a>> wrote:<br><blockquote type="cite">We assume WF is in paused/errored state when 1) user manually pause the WF,<br>2) pause is specified on transition (on-condition(s) such as on-error), and<br>3) task errored.<br><br>The resume feature will support the following use cases.<br>1) User resumes WF from manual pause.<br>2) In the case of task failure, user fixed the problem manually outside of<br>Mistral, and user wants to re-run the failed task.<br>3) In the case of task failure, user fixed the problem manually outside of<br>Mistral, and user wants to resume from the next task.<br></blockquote>this use case does really make sense to me.<br><blockquote type="cite"><br>Resuming from #1 should be straightforward.<br>Resuming from #2, user may want to change the inbound context.<br>Resuming from #3, users is required to manually provide the published vars<br>for the failed task(s).<br><br>In our offline discussion, there's ambiguity with on-error clause and<br>whether a task failure has already been addressed by the WF itself. In many<br>cases, the on-error tasks may just be logging, email notification, and/or<br>other non-recovery procedures. It's hard to determine that automatically,<br>so we let users decide where to resume the WF instead. Mistral will let<br>user resume a WF from specific point. The resume function will determine the<br>requirements needed to successfully resume. If requirements are not met,<br>then resume returns an error saying what requirements are missing. In the<br>case where there are failures in multiple parallel branches, the<br>requirements may include more than one tasks. For cases where user<br>accidentally resume from an earlier task that is already successfully<br>completed, the resume function should detect that and throw an exception.<br><br>Also, the current change to separate task from action execution should be<br>sufficient for traceability.<br><br>We also want to expose an endpoint to let users view context for a task.<br>This is to let user have a reference of the current task context to<br>determine the delta they need to change for a successful resume.<br></blockquote>IMHO, I'm afraid I can't agree here. The context for a task is used<br>internally, I know the aim for this feature is to make it very easy<br>and convinient for users to see the details for the workflow exection,<br>but what users can do next with the context? Do you have a plan to<br>change that context for a task by users? if the answer is no, I think<br>it is not very necessary to expose the context endpoint.<br><br>However, considering the importance of context for the task<br>execution(the resuming feature), we can introduce the notification<br>system to Mistral, which is heavily used in other OpenStack projects.<br><blockquote type="cite"><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe:<span class="Apple-converted-space"> </span><a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br><br></blockquote><br><br><br>--<span class="Apple-converted-space"> </span><br>Regards!<br>-----------------------------------<br>Lingxian Kong<br><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe:<span class="Apple-converted-space"> </span><a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></blockquote></div><br></div></body></html>