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
extensions
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.
Regards,
-- Erez
From: "David P Grove" <[email protected]>
To: [email protected]
Date: 06/12/2018 18:37
Subject: Re: Shared Context in OpenWhisk - Fixed format
"Erez Hadad" <[email protected]> wrote on 12/06/2018 11:20:26 AM:
>
> 5. Implementation cost - not sure it's that great, but I need to study
the
>
> issue more. I put one slide in the backup section of the presentation
> listing the main components involved, and this could be further
discussed.
>
> For example, I think that environment variables are provided as a
package
> 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,
and
the controller to propagate context modifications back along with the
action result.
--dave
