FWIW, I don't think of this as a huge change, meaning no change is required at
invoker/controller. Rather it is just a convention for context value access
within functions and function signature that is already unique to each language
runtime, and requires possibly supporting 2 runtimes per language+convention
while transitioning to the new convention. This convention is exposed to
function developers so "replacing it" is not really an option, I think, but
rather requires graceful deprecation and migration (with developers
participation).
e.g. for nodejs, the old convention used for signature and context is:
- function signature is `<function> (args)`
- context is `process.env.<context key>`
New convention for signature and context is:
- function signature is `<function> (contextObject, args)`
- context is ` contextObject.<context key>`
So you can feasibly:
* create a new runtime for nodejs that uses new convention
* add a separate kind for using the new runtime
* gradually phase out use of old kind (communication, deprecation, etc)
I just want to throw this out there because I get the feeling whenever we
discuss "context" that there is misconception around the need to change the
invoker to support this. There is surely some parts of the invoker/action
container protocol that may be further cleaned up to isolate static values
(action name) from per-activation context (activation id), but I don't think
that is required to start changing the conventions for function signature to
include context as a separate object from activation params.
Thanks
Tyson
On 5/2/19, 8:54 AM, "David P Grove" <gro...@us.ibm.com> wrote:
Rodric Rabbah <rod...@gmail.com> wrote on 05/02/2019 11:05:35 AM:
>
> any existing java function that uses the environment variables would have
> to be modified.
> i would not change it - openwhisk has a uniform model across all the
> runtimes and this would start to diverge... i can be convinced but
instinct
> is to leave it alone.
>
I think the change could be justified if it was part of a broader redesign
to enable concurrent activations in a runtime.
1. pass in a context object instead of stashing activation-specific
params in the environment
2. require proper structured logging
--dave
