openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodric Rabbah <rod...@gmail.com>
Subject Re: Change the way the java runtime handles envirorment variable
Date Thu, 02 May 2019 17:11:16 GMT
I agree that any such change doesn’t need to touch the invoker except to potentially remove
one variable from the environment (api host). 


-r

> On May 2, 2019, at 12:11 PM, Tyson Norris <tnorris@adobe.com.invalid> wrote:
> 
> 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" <groved@us.ibm.com> wrote:
> 
> 
> 
>    Rodric Rabbah <rodric@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
> 
> 

Mime
View raw message