openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Allen <...@akrabat.com>
Subject Re: exporting activation arguments to the environment
Date Wed, 26 Jun 2019 06:36:46 GMT
Hi,

I have always been in favour of separating the parameters that are set by the developer/environment
(context) from those that are input data for this particular-activation. For me its about
which ones we trust and which ones we don't. 

i.e. database credentials and the activation id are conceptually different from POSTed data
and this should be obvious in my code as it means fewer mistakes and makes code-reviews that
much easier. 

Regards,

Rob


> On 25 Jun 2019, at 23:07, Tyson Norris <tnorris@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" <rodric@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
> 
> 

-- 
Development thoughts at http://akrabat.com
Daily Jotter for macOS at http://dailyjotter.com


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