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
examples).
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.
-r
On Wed, Jun 26, 2019 at 1:21 PM Tyson Norris <[email protected]>
wrote:
> 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" <[email protected]> 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 <[email protected]>
> 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" <[email protected]> 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
> >
> >
>
>
>
