openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominic Kim <style9...@gmail.com>
Subject Re: Change the way the java runtime handles envirorment variable
Date Wed, 08 May 2019 02:25:25 GMT
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 <rodric@gmail.com>님이 작성:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message