<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 03/21/2014 12:33 AM, W Chan wrote:<br>
</div>
<blockquote
cite="mid:CABNy8O4j3FwxB3V6OohvG_ndoEj2jy7eJbPtRMN2wCB0D84vSA@mail.gmail.com"
type="cite">
<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>
</div>
</blockquote>
Look into the "Trusts" capability of Keystone for Authorization
support on long running tasks.<br>
<br>
<br>
<blockquote
cite="mid:CABNy8O4j3FwxB3V6OohvG_ndoEj2jy7eJbPtRMN2wCB0D84vSA@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Mar 20, 2014 at 3:07 PM, Dmitri
Zimine <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:dz@stackstorm.com" target="_blank">dz@stackstorm.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<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
moz-do-not-send="true"
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 class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>DZ> </div>
<div><br>
</div>
</font></span></div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
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>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>