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 Tue, 07 May 2019 12:35:34 GMT
callback is gone in newer node versions in AWS lambda and you can return a promise which makes
the difference between the lambda and openwhisk signature specific to context. 

Note that lambda is less uniform in signatures and models across languages. Annoyingly. 

-r

> On May 7, 2019, at 8:28 AM, James Thomas <jthomas.uk@gmail.com> wrote:
> 
> I'd definitely prefer to see us have a more generic discussion on changing
> all runtimes to provide the context as an invocation parameter, rather than
> having per-runtime fixes. This doesn't affect the invokers AFAIK.
> 
> Moving to providing a second `context` argument would have the advantage of
> mirroring other serverless platforms, e.g. AWS Lambda.
> 
> exports.*myHandler* = function(event, context, callback) {
>    *... function code*
>    callback(null, "some success message");
>   // or
>   // callback("some error type");
> }
> 
> 
> 
>> On Thu, 2 May 2019 at 18:11, Rodric Rabbah <rodric@gmail.com> wrote:
>> 
>> 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
>>> 
>>> 
>> 
> 
> 
> -- 
> Regards,
> James Thomas

Mime
View raw message