openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Olivier Tardieu" <>
Subject Re: Pausing actions, waiting for human input etc.
Date Tue, 26 Mar 2019 17:10:15 GMT

With suspend/resume (or parallel in composer today) you have to give up 
as Rodric pointed out. While results (intermediate or final) of 
long-running compositions
can appear in activation records, finding the corresponding activation 
records amounts
to finding a needle in a haystack as OpenWhisk default activation database 
does not permit fancy queries. Lack of substitution also means that quotas 
and throttles
are in effect. Concretely, an execution may fail to resume because the 
account is over its

It is possible to implement suspend and resume today by dynamically 
creating triggers
and rules. An action could in principle create an alarm trigger and a rule 
to reinvoke itself
at a later point in time or invoke the next action in a logical sequence. 
The trigger can even
embed state. Of course, building actions that can save their state and 
resume execution
from a saved state requires either some no-trivial coding or composer-like 
code generation.

There are two main concerns with this approach:
1. garbage collection: the triggers and rules should be deleted after use 
(relatively easy) or when
something unexpected happen, eg, timeout (harder).
2. while OpenWhisk is meant to handle lots of activations, I don't think 
it is meant
to handle lots of creation and deletion operations. But maybe you don't 
need a lot.

Alternatively, the dynamic creation of trigger-like and rule-like things 
can be pushed to
an external system outside of OpenWhisk. This addresses issue number 2 and 
can also
help with 1 as such a system may have built-in support for some form of 

Handling external inputs as opposed to sleep/alarm scenarios further 
complicates things
as order and concurrency control potentially become an issue. Nothing in 
itself guarantees that external inputs would be processed in order or that 
would not be processed concurrently. Of course, if user inputs are few and 
far between
this may not be a concern for your scenario. In general, there is no 
simple solution.

I did experiment with these approaches for composer in the past but I did 
not feel
there was enough interest in the community to warrant a serious 


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message