openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodric Rabbah <>
Subject Re: Pausing actions, waiting for human input etc.
Date Tue, 26 Mar 2019 15:10:27 GMT
I'll defer to Olivier Tardieu on this topic but brliefly, with an external
medium for preserving state, e.g., Redis (which you need for parallel
combinators), this is possible... This may have even existed at one point
in the past.

Compositions with OpenWhisk intrinsic support provide for three features
that are unique to our orchestration (these were the subject of a
publication [1]):
1. black box actions can be composed (functions are not modified)
2. no double billing (in space or time, ie the conductor action which
orchestrated the composition is not waiting for actions to finish and
holding on to resources)
3. substitution, meaning compositions themselves are further composable
because they are like other actions

With a combinator for suspend/resume, you give up substitution --- since
the system has to generate an activation record for the parent activation
and cannot wait indefinitely. So suspending the composition terminate the
first execution and a later resume creates a new activation. Whether the
two can be linked through some causality reference is desirable but
orthogonal, I think.

[1] The Serverless Trilemma: Function Composition for Serverless Computing

On Tue, Mar 26, 2019 at 9:25 AM Bertrand Delacretaz <>

> Hi,
> I'm looking at a way to execute long-running compositions of Actions,
> including waiting for human inputs with long timeouts in the range of
> several days.
> The basic pattern is something like
>    wsk.suspend(someEvent)
>    // this line executes only after that someEvent is received
> AFAIK that's not currently possible out of the box - but I'd be happy
> to be proven wrong!
> Is anyone working on something similar, or are there any prototypes
> around that go in that direction?
> Two initial ideas that come to mind is taking inspiration from the way
> the Composer's Parallel combinator saves state [1], or pausing between
> invocations of Conductor Actions [2]. I haven't looked at the details
> of how those work so far.
> -Bertrand
> [1]
> [2]

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