openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodric Rabbah <>
Subject Re: exporting activation arguments to the environment
Date Wed, 26 Jun 2019 17:42:14 GMT
Maybe this got missed, but here's how I conceived of this. I'll use wsk CLI
commands, I think it makes it obvious.

wsk action create myAction code.js -p MY_ENV true -p some_param false -a
partition-arguments true

The annotation (partition-arguments) makes it explicit for the developer to
control whether "main" receives the arguments as they do today, which is
this object
{ MY_ENV: true, some_param: false}, or when the annotation is true, {
some_param: false} and process.env.MY_ENV is set to true.

I don't think there's anything confusing about this in that the developer
has decided what variables to export to the environment, and is making an
explicit choice.

Environment variables on a number of platforms are restricted to those at
consist of words that start with capital letter (AWS, Netlify as two prime

The alternative, today, requires a function to export any variables from
"main" to the environment. So it would explicitly export MY_ENV to the
environment. The change we're discussing frees the programmer from having
to do that.

The change to the runtime proxies would be 1. accept an additional value on
/init and export all the properties it contains to the environment.

Before I address the POST invoke issue, I'd like to make sure my
explanation is clearer and if this is still controversial.


On Wed, Jun 26, 2019 at 1:21 PM Tyson Norris <>

> Are you saying one is exported to environment, during init, based on
> parameter name being UPPER case? Forgetting use of env vars for a minute,
> this seems confusing to treat parameters different based on names. I would
> rather see either a) all action-configured params sent to init only, and
> never to run or b) all action-configured params sent to run as context
> object.
> What the runtime does at init (use env vars or not) can be different per
> runtime, but in the action-configured parameter case I don't see any
> problem with setting env vars, except that there seems to be a convention
> in some cases that allows invoking clients to "override" these values using
> POST parameters at invocation time. This also seems confusing but could
> also be enforced differently by various runtimes, although ideally I would
> rather see the convention change to: action-configured parameters are
> always sent to init, and always visible to run, regardless of what client
> sends as execution parameters.
> Thanks
> Tyson
> On 6/25/19, 3:32 PM, "Rodric Rabbah" <> wrote:
>     Context and Knative I view as orthogonal.
>     That is, for the context object, it is another way of encapsulating
> arguments. It doesn’t export variable to the process environment.
>     You can provide an action with both environment variables, arguments
> to main, and a context object. They are orthogonal.
>     For the context object, the distinction that was necessary from
> previous discussions was related to separating intra container concurrent
> executions. If the system-provided context is exported to the environment
> as it today the values clobber each other. For this, the context object
> would make sense.
>     I’m simply talking about two parameters wsk ... “-p a A” and “-p B b”
> say where one becomes exported to the environment as B=b and the other is
> passed to the action as ({a:A}).
>     I’m going to set the knative discussion aside because I think it’s a
> distraction. With knative you can bind environment variables to the
> container. As you would with any other container.
>     I think it’s too simplistic to say knative has a single endpoint.
> After all there are readiness probes and possible pre/post start hooks that
> operators may have to deal with. Init can be viewed as the readiness probe.
>     Fundamentally I believe the actor model is much better aligned with
> the reactive programming model for functions so this will tend toward a
> completely different discussion in my view.
>     The reason my proposal sets the environment variables at init time is
> that’s how env vars work;  they exist before you start you process. While
> they don’t need to be immutable, it makes sense to test them as such.
>     For webaction parameters that one would export to an environment, they
> are already immutable and cannot be overridden. So really you would not use
> them for anything that varies per activation.
>     The view here is that you can export global (immutable) variables to
> the action. This makes it easier to take existing code and containers which
> might use env vars and use them almost off the shelf.
>     -r
>     > On Jun 25, 2019, at 6:07 PM, Tyson Norris <>
> wrote:
>     >
>     > I had to read this several times, but have some suggestions. I think
> when you say "action's arguments", you mean action-configured params, e.g.
> `wsk action create --param p1 v1`?
>     >
>     > My preferences would be:
>     > - we should split off "run" args into context and params - this is
> the convention change for redefining main(args) as main(context, args) we
> have discussed in the past.
>     > - I support either having init receive action-configured params
>     > - activation args that are possibly overridden should behave exactly
> as specified args - is it important that action-configured args are
> actually overridden, if the context and params are separated? (receive both
> values, and logic must decide when to use which)
>     > - let's not use env variables for any arg that is variable per
> activation - it is impossible if you support concurrency, and unneeded if
> we pass the context to "run".
>     >
>     > Regarding Matt's suggestion to remove init - I like this idea, but I
> have concerns compared to knative which might serve every function with a
> different container, vs having some containers reused for multiple
> functions. In the case where we init code into an already running
> container, it is useful to have the init process separate from run, since
> otherwise each runtime will need to track its own init state and queue
> requests during init etc. If I'm not getting the whole picture with
> knative, please correct me.
>     >
>     >
>     > Thanks
>     > Tyson
>     >
>     > On 6/24/19, 8:43 AM, "Rodric Rabbah" <> wrote:
>     >
>     >    In the current activation model, an action's arguments are always
> provided
>     >    to the action on "run", not "init".
>     >
>     >    Should we consider partitioning the argument list into two sets,
> the first
>     >    is exported as environment variables at "init" time, and the
> second become
>     >    the action's argument at "run" time? A criteria for partitioning
> is that
>     >    the environment variable starts with a capital letter, which is a
> common
>     >    convention.
>     >
>     >    For example, an action which is invoked with a JSON object
>     >
>     >    { "XYZ": true,
>     >      "abc" : false }
>     >
>     >    would receive {"abc": false} as its arguments and can read XYZ
> from the
>     >    environment (as process.env.XYZ == "true" in Node.js).
>     >
>     >    This change would:
>     >    1. require a change in the invoker to pass arguments during
> initialization
>     >
>     >    2. require a change in the runtime proxies to export the
> arguments to the
>     >    environment at initialization time (additional work may be
> implied by 1b)
>     >
>     >    3. an annotation on actions to opt into this partitioning for
> backward
>     >    compatibility or to opt out. For example '-a
> env-partition-arguments true'
>     >    partitions the arguments and actions without this annotation are
> not
>     >    affected.
>     >
>     >    Some obvious question:
>     >    Q1a. should the invoker perform the partitioning or delegate it
> to the
>     >    runtime? The advantage of the former is that the runtimes do not
> have to
>     >    implement the filtering policy and do less work. I think it makes
> sense to
>     >    do this invoker side for uniformity.
>     >
>     >    Q1b. should the partitioning treat environment variables as
> immutable post
>     >    init and ignore the partition on warm starts? This is an issue
> when a value
>     >    is overridden during POST invoke only since for a webaction, you
> cannot
>     >    override a value that's already defined (and updating a bound
> parameter on
>     >    an action invalidates warm containers). I think env vars should
> be treated
>     >    as immutable despite the issue with POST invoke.
>     >
>     >    -r
>     >
>     >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message