openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <>
Subject Re: exporting activation arguments to the environment
Date Thu, 27 Jun 2019 11:46:32 GMT
I understand that this is orthogonal on what Rodric is proposing but for the topic of environment

Reserved 2 annotations to be private like “__OW_CONFIGS” and “__OW_SECRETS”
No schema change 

This variables would be dictionaries/jsonobjects

The information will end up as environment variables at runtime. 

Then provide an user experience thru UI or CLI to set both

Example of CLI:
wsk action update myaction myaction.js -c LOGLEVEV DEBUG -s PASSWORD supersecret 

Both LOGLEVEL and PASSWORD will be set as environment variables 

The idea to brake them into two sets give the opportunity to the operator and the management
platform to treat secrets a bit different if desired. 

- Carlos Santana

> On Jun 27, 2019, at 6:00 AM, Dominic Kim <> wrote:
> I am inclined to be more explicit.
> Whenever users forget about the difference between uppercase and lowercase
> parameters, the feature may not work as they expected.
> So I am inclined to Tyson's opinion to explicitly add another flag such as
> "-e".
> If it could be overhead to change the schema, how about relying on
> annotation?
> I think it makes sense to set environment variables at action creation time.
> We can introduce a new annotation to set environment variables, or apply
> some rules against the existing flag "-a" as Rabbah suggested.
> Best regards
> Dominic
> 2019년 6월 27일 (목) 오전 8:52, Rodric Rabbah <>님이 작성:
>> The use of env vars wouldn't be an issue with intra-container concurrency
>> if they're immutable, right? The more specific issue that arises today
>> which I think is your primary concern, are the __OW_ system provided
>> environment variables which mutate with each invocation of main. Is that
>> right?
>> If so, then I think there are only two issues:
>> 1. do we introduce a context object (did you see my other dev list mail?)
>> 2. logging
>> i really think my issue is orthogonal to these concerns - it's a
>> convenience feature for the developer.  An action can already export
>> environment variables today from main.
>> -r
>> On Wed, Jun 26, 2019 at 8:44 PM Tyson Norris <>
>> wrote:
>>> Sorry, what I meant was: accumulating issues around the "main" function,
>>> which are:
>>> - context
>>> - use of env vars
>>> - your issue: separating user provided params from developer-provided
>>> params
>>> - completely separate, but worth noting: logging (and env vars) in the
>>> face of concurrency
>>> On 6/26/19, 5:29 PM, "Rodric Rabbah" <> wrote:
>>>> There are some accumulating issues around init and run.
>>>    Which issues are these?
>>>    -r

View raw message