
<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;" class=""><div class="">Hi,</div><div class=""><br class=""></div>Thanks guys for bringing this topic up to discussion. In my opinion, this feature is <b class="">extremely</b> important and will move Mistral further to being a truly useful tool. I think it’s one of the “must have” feature of Mistral.<div class=""><br class=""></div><div class=""><div apple-content-edited="true" class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On 31 Mar 2015, at 08:56, Dmitri Zimine <<a href="mailto:dzimine@stackstorm.com" class="">dzimine@stackstorm.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">@Lingxian Kong</div><div class=""><blockquote type="cite" class=""> The context for a task is used<br class="">internally, I know the aim for this feature is to make it very easy<br class="">and convinient for users to see the details for the workflow exection,<br class="">but what users can do next with the context? Do you have a plan to<br class="">change that context for a task by users? if the answer is no, I think<br class="">it is not very necessary to expose the context endpoint.</blockquote><div class=""><br class=""></div>I think the answer is “yes users will change the context” this falls out of use case #3. </div><div class="">Let’s be specific: a create_vm task failed due to, say, network connection. </div><div class="">As a user, I created the VM manually, now want to continue the workflow. </div><div class="">Next step is attach storage to VM, needs VM ID published variable. So a user needs to </div><div class="">modify outgoing context of create_vm task.</div></div></div></blockquote><div><br class=""></div><div>Agree with Dmitri here.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">May be use case 2 be sufficient? </div><div class="">We are also likely to specify multiple tasks: in case a parallel execution of two tasks</div><div class="">(create VM, create DNS record) failed again due to network conditions - than network </div><div class="">is back I want to continue, but re-run those two exact tasks. </div><div class=""><br class=""></div><div class="">Another point, may be obvious but let’s articulate it: we re-run task, not individual action within task.</div><div class="">In context of with_items, retry, repeat, it will lead to running actions multiple times.</div><div class=""><br class=""></div><div class="">Finally, workflow execution traceability. We need to get to the point of tracing pause and resume as workflow events. </div><div class=""><br class=""></div><div class="">@Lingxian Kong</div><div class=""><blockquote type="cite" class=""> we can introduce the notification<br class="">system to Mistral, which is heavily used in other OpenStack projects.</blockquote>care to elaborare? Thanks! </div></div></div></blockquote><div><br class=""></div><div>I’m curious too. Lingxian, could you please explain more detailed what you mean exactly?</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><blockquote type="cite" class=""><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;" class="">On Fri, Mar 27, 2015 at 11:20 AM, W Chan <<a href="mailto:m4d.coder@gmail.com" class="">m4d.coder@gmail.com</a>> wrote:<br class=""><blockquote type="cite" class="">We assume WF is in paused/errored state when 1) user manually pause the WF,<br class="">2) pause is specified on transition (on-condition(s) such as on-error), and<br class="">3) task errored.<br class=""><br class="">The resume feature will support the following use cases.<br class="">1) User resumes WF from manual pause.<br class="">2) In the case of task failure, user fixed the problem manually outside of<br class="">Mistral, and user wants to re-run the failed task.<br class="">3) In the case of task failure, user fixed the problem manually outside of<br class="">Mistral, and user wants to resume from the next task.</blockquote><blockquote type="cite" class=""><br class="">Resuming from #1 should be straightforward.<br class=""></blockquote></div></blockquote></div></div></div></div></blockquote><div><br class=""></div>Just to clarify: this already works.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><blockquote type="cite" class=""><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;" class=""><blockquote type="cite" class="">Resuming from #2, user may want to change the inbound context.<br class="">Resuming from #3, users is required to manually provide the published vars<br class="">for the failed task(s).<br class=""></blockquote></div></blockquote></div></div></div></div></blockquote></div></div><div class=""><div class=""><br class=""></div><div class="">These two cases is basically what we need to implement.</div><div class=""><br class=""></div><div class="">Winson, very good and clear summary (at least to me). I would suggest we prepare a little bit more formal (but not too much) spec of what we’re going to do here. A few examples would help us understand the topic better. So specifically, it would be interesting to see:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">What endpoints we are going to add and how approximately they would look (calculating requirements that need to be satisfied in order to resume workflow, task contextx).</li><li class="">A few typical scenarios of resuming a workflow with explanations of how we modify contexts or published vars and how we resume the workflow. The trivial case (#1) can be skipped as it’s already implemented.</li><li class="">Roughly formed suggestions on how that all could be implemented.</li></ul></div><div class=""><br class=""></div><div class="">This is just my preference to see something like this but at the same time I personally don’t want you to spend much time on that but if it’s possible to prepare it within a reasonable amount of time that would be helpful</div><div class=""><br class=""></div><div class="">Thanks</div><div class=""><br class=""></div><div class="">Renat Akhmerov</div><div class="">@ Mirantis Inc.</div></div><div class=""><br class=""></div></body></html>