Hi Vadim, thanks for bringing this up!
If I were to design a new system from the ground up, I'd definitely introduce a new structure to have a good distinction between environment and parameters. Taking into consideration that we need to be backwards compatible, I'd definitely choose option 1. It will at least enable existing workloads (think: blackbox containers built on the skeleton) to continue working without intervention, which is key for us. Regarding adding "value" as well: Is there any cost when setting environment variables, especially with very large values? Is there a limitation on the value of environment variables? I guess we could blacklist "value" fairly easily as well? Cheers, Markus Am Mo., 6. Aug. 2018 um 10:07 Uhr schrieb Vadim Raskin <[email protected]>: > > Hi, > > > currently the list of system environment variables that are exposed in user > containers is configured in several places. First in the Invoker, it > defines api_host env var during container creation, the rest of the env > vars is configured for each run command via passing a json object [1] as a > payload to container’s /run endpoint. Second the exact environment > variables to be exposed are defined in each particular runtime, see the > example for nodejs [2]. > > > The problem here is that we limit the exposed env vars in several places > (invoker, each runtime) which makes it cumbersome to introduce changes. > > > One possible option to alleviate introduction of new env vars would be to > simply expose all properties found on the root level of the json structure > excluding the “value”. In this case all runtimes must be updated. > > > Another option for the same approach would be to introduce a new structure > on the root level called “env_vars” which will encompass all vars to be > exposed. In this case changes for both Invoker and all runtimes would be > required. > > > Do you have any concerns here? Which option sounds better? > > > Thank you, > Vadim > > > [1] > { > “value”:{} > “namespace”:”” > “action_name”:”” > “activation_id”:”” > “deadline”:”” > “api_key”:”" > } > [2] The list of environment variables to be exposed boils down to these > ones: namespace, action_name, activation_id, deadline, api_key. > https://github.com/apache/incubator-openwhisk-runtime-nodejs/blob/master/core/nodejsActionBase/src/service.js#L161
