A side query - How would use of such env variables work with concurrent activation support? As env variables cannot be mapped per thread we would not be able to rely on them if concurrent activations are to be used
Should we reduce dependency on env variable to communicate such state? Chetan Mehrotra On Mon, Aug 6, 2018 at 1:56 PM Markus Thömmes <[email protected]> wrote: > 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 >
