<div dir="ltr">Don't forget HA issues. Mistral can be restarted at any moment and need to be able to proceed from the place it was interrupted on another instance. In theory it can be addressed by TaskFlow but I'm not sure it can be done without complete redesign of it<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 21, 2014 at 8:33 AM, W Chan <span dir="ltr"><<a href="mailto:m4d.coder@gmail.com" target="_blank">m4d.coder@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Can the long running task be handled by putting the target task in the workflow in a persisted state until either an event triggers it or timeout occurs? An event (human approval or trigger from an external system) sent to the transport will rejuvenate the task. The timeout is configurable by the end user up to a certain time limit set by the mistral admin. <div>
<br></div><div>Based on the TaskFlow examples, it seems like the engine instance managing the workflow will be in memory until the flow is completed. Unless there's other options to schedule tasks in TaskFlow, if we have too many of these workflows with long running tasks, seems like it'll become a memory issue for mistral...</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Thu, Mar 20, 2014 at 3:07 PM, Dmitri Zimine <span dir="ltr"><<a href="mailto:dz@stackstorm.com" target="_blank">dz@stackstorm.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif">
<div>For the 'asynchronous manner' discussion see <a href="http://tinyurl.com/n3v9lt8" target="_blank">http://tinyurl.com/n3v9lt8</a>; I'm still not sure why u would want to make is_sync/is_async a primitive concept in a workflow system, shouldn't this be only up to the entity
running the workflow to decide? Why is a task allowed to be sync/async, that has major side-effects for state-persistence, resumption (and to me is a incorrect abstraction to provide) and general workflow execution control, I'd be very careful with this (which
is why I am hesitant to add it without much much more discussion).</div>
</div></blockquote></div><div><br></div><div>Let's remove the confusion caused by "async". All tasks [may] run async from the engine standpoint, agreed. </div><div><br></div><div>"Long running tasks" - that's it.</div>
<div><br></div><div>Examples: wait_5_days, run_hadoop_job, take_human_input. </div><div>The Task doesn't do the job: it delegates to an external system. The flow execution needs to wait (5 days passed, hadoob job finished with data x, user inputs y), and than continue with the received results.</div>
<div><br></div><div>The requirement is to survive a restart of any WF component without loosing the state of the long running operation.</div><div><br></div><div>Does TaskFlow already have a way to do it? Or ongoing ideas, considerations? If yes let's review. Else let's brainstorm together. </div>
<div><br></div><div>I agree,</div><div><blockquote type="cite"><div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif">that has major side-effects for state-persistence, resumption (and to me is a incorrect abstraction to provide) and general workflow execution control, I'd be very careful with this</div>
</blockquote></div><div>But these requirement comes from customers' use cases: wait_5_day - lifecycle management workflow, long running external system - Murano requirements, user input - workflow for operation automations with control gate checks, provisions which require 'approval' steps, etc. </div>
<span><font color="#888888"><div><br></div><div>DZ> </div><div><br></div></font></span></div><br></div></div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small">Sincerely yours<br>
Stanislav (Stan) Lagun<br>Senior Developer<br>Mirantis</span></span><br><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"" lang="EN-US">35b/3, Vorontsovskaya
St.</span><br>Moscow, Russia<br>Skype: stanlagun<br><a href="http://www.mirantis.com/" target="_blank">www.mirantis.com</a><br><a href="mailto:slagun@mirantis.com" target="_blank">slagun@mirantis.com</a></span></span></div>
</div>