openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erez Hadad" <>
Subject Re: Shared Context in OpenWhisk - Fixed format
Date Sun, 09 Dec 2018 13:12:34 GMT
Hi Dave,

I explained this in the presentation (slides 5 and 10), but possibly not 
clearly enough.

I propose two changes to support the context propagation:
1. Extend the REST APIs of "invoke action" and "trigger fire" to allow 
specifying context.
2. Intercept the outgoing invocations of a client to transparently inject 
the client's own context into the outgoing invocation request in addition 
to the client's explicitly stated new context, using the above API 

For change #2, I propose to implement it at least initially in the 
OpenWhisk client libraries (in JS, Go and Python). 
For example, when using a OW JS client library, we now have the following 
API for action invocation:
ow.actions.invoke({name, blocking, result, params})

After the proposed changes, the new API will be:
ow.actions.invoke({name, blocking, result, params, context})
and its behavior will be to inspect the caller's context (available e.g., 
via environment variables), copy it (if it's not empty) and append the 
context provided as a parameter above, resulting in the context that needs 
to go into the REST request.

This way, there is no need to modify the runtimes beyond support for the 
context itself. 
Of course, clients that do not use client libraries may break propagation, 
but I think that should become a rare case.
There are other ways to transparently handle the context propagation 
(e.g., transparent proxy) but I think this is a clean and cheap one to 
begin with.

-- Erez

From:   "David P Grove" <>
Date:   06/12/2018 18:37
Subject:        Re: Shared Context in OpenWhisk - Fixed format

"Erez Hadad" <> wrote on 12/06/2018 11:20:26 AM:
> 5. Implementation cost - not sure it's that great, but I need to study
> issue more. I put one slide in the backup section of the presentation
> listing the main components involved, and this could be further
> For example, I think that environment variables are provided as a 

> to the runtimes, so adding one more env. var. should make no code
> difference in the runtimes. Alternatively, if using external storage
> (e.g., Redis) for all the context, the key can simply be the activation
> id, which is already there, so no code change at either invoker or
> runtimes. A separate library or service can implement the access to the
> context.

If not using external storage, how do additions to the shared context get
back to the controller so they can be flowed to the next action?

At first glance, this involves modifying all the runtimes, the invoker, 
the controller to propagate context modifications back along with the
action result.


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