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" <rod...@gmail.com> 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 <tnor...@adobe.com.invalid>
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" <rod...@gmail.com> 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
>
>
