> For the 'asynchronous manner' discussion see http://tinyurl.com/n3v9lt8; 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).


Let's remove the confusion caused by "async". All tasks [may] run async from 
the engine standpoint, agreed. 

"Long running tasks" - that's it.

Examples: wait_5_days, run_hadoop_job, take_human_input. 
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.

The requirement is to survive a restart of any WF component without loosing the 
state of the long running operation.

Does TaskFlow already have a way to do it? Or ongoing ideas, considerations? If 
yes let's review. Else let's brainstorm together. 

I agree,
> 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

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. 

DZ> 

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to