This might a little bit aside from the discussion. But one thing I want to mention on environment variables or context is, I hope users can set up them differently than parameters.
One use case of environment variables could be supplying some secrets or private data in shared-package actions. If a user shares his package and an action inside of it requires some secrets, the context arguments would help this work. IIRC, there was a discussion on general permission enhancement, and what I mentioned above can be achieved differently with enhanced permission supports as well, but I just want to show an example that environment variables can be used differently. In this sense setting up `context` values just like `parameters` is not that useful. We need a different mechanism for users to set up them. `Parameters` are already acting as a good way to provide inputs or data. So if we decide to include the context as an invocation parameter, I hope we can define a new mechanism for them rather than just setting up another `parameters` and passing them at runtime. Best regards Dominic 2019년 5월 7일 (화) 오후 9:35, Rodric Rabbah <[email protected]>님이 작성: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > >> 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" <[email protected]> wrote: > >>> > >>> > >>> > >>> Rodric Rabbah <[email protected]> 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 >
