openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Allen <>
Subject Re: exporting activation arguments to the environment
Date Thu, 27 Jun 2019 11:51:25 GMT

In general, I'd rather see a different switch such as `-e` for setting environment variables
as I'm suspicious of a `param` having different meanings which risks confusion.



> On 27 Jun 2019, at 01:21, Tyson Norris <> wrote:
> For the incremental change I would suggest:
> - include the action-configured params as args to init
> - optionally: include an invoker flag to optionally remove action-configured params from
being sent to run (these would only be available by way of init setting env vars, or exposing
some other object)
> - runtimes can be updated incrementally to support this flagged invoker behavior
> I understand the point on amount of work, I'm just not wanting to sacrifice an awkward
behavior (different treatment for params in upper case) for sake of time. There are some accumulating
issues around init and run so I'm not sure it is worth making the problem worse before addressing
the other issues. I think its ok to change init to receive these params as a minimal change,
but obviously without additional changes either at invoker or in OW's convention for designing
functions (main sig, how to access init vars, context) there will be some incremental pain
as well. 
> Still curious what others think.
> ´╗┐On 6/26/19, 11:27 AM, "Rodric Rabbah" <> wrote:
>> Sorry, it still seems controversial to me, not sure how others feel?
>    That's why we discuss on the dev list :D Thanks for the feedback so far.
>> can you confirm this is decided based on the case of the parameter name?
>    Indeed, we need some rule to then partition the parameter list. Using the
>    convention that the env var starts with a capital letter is one. Other
>    conventions are plausible.
>> adding a '-e' flag that specifically does "set these environment
>    variables"
>    Sure - but this increases the complexity of implementation significantly
>    for not a lot of gain. To add a -e, we'd need to modify the schema for
>    actions. For example, we could add annotation for each parameter name to be
>    treated as an environment variable using the existing annotations, and use
>    these annotations as the criteria. We could create a new field in the
>    actions object to hold the parameters (a schema change). We could annotate
>    each parameter (also a schema change).
>    Since a developer already controls the names of their parameters today,
>    they have complete control over this partitioning.
>    If we're open to schema changes, then we can explore a cleaner
>    implementation but an incremental approach that at least makes the feature
>    available incrementally would also make sense since making a schema change
>    is a lot more invasive, coupled with a few changes needed at the invoker
>    level plus all the runtimes.
>    -r

Development thoughts at
Daily Jotter for macOS at

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