tysonnorris opened a new issue #4020: avoid using env vars in /run in runtimes URL: https://github.com/apache/incubator-openwhisk/issues/4020 <!-- We use the issue tracker for bugs and feature requests. For general questions and discussion please use http://slack.openwhisk.org/ or https://openwhisk.apache.org/contact.html instead. Do NOT share passwords, credentials or other confidential information. Before creating a new issue, please check if there is one already open that fits the defect you are reporting. If you open an issue and realize later it is a duplicate of a pre-existing open issue, please close yours and add a comment to the other. Issues can be created for either defects or enhancement requests. If you are a committer than please add the labels "bug" or "feature". If you are not a committer please make clear in the comments which one it is, so that committers can add these labels later. If you are reporting a defect, please edit the issue description to include the information shown below. If you are reporting an enhancement request, please include information on what you are trying to achieve and why that enhancement would help you. For more information about reporting issues, see https://github.com/apache/incubator-openwhisk/blob/master/CONTRIBUTING.md#raising-issues Use the commands below to provide key information from your environment: You do not have to include this information if this is a feature request. --> This is to discuss replacing use of environment variables in runtimes with some other object ( e.g. "context") that is explicitly provided to actions, to avoid issues when runtimes support concurrent activation processing, and simplify the per-activation metadata provided to action developers. _This requires no change in OW core, but does require changes in all runtimes (assuming consistency is important) so rather than create many issues across all repos, I'm creating this one issue to start with..._ Some discussion here: https://lists.apache.org/thread.html/4b75db671e5f52c11bad6e3073c4cb4170d2ef0fdfb0cd73bed259b0@%3Cdev.openwhisk.apache.org%3E In general, during concurrent activation processing, referring to (e.g. in nodejs case) process.env will be inaccurate, if that is set during each activation as is done now: https://github.com/csantanapr/incubator-openwhisk-runtime-nodejs/blob/master/core/nodejsActionBase/src/service.js#L163 However, disabling process.env usage will be a breaking change. A general plan for deprecating env var usage and allowing migration to new main signatures should be provided. For nodejs, we can: - enhance process.env with a dynamic (getter) property a la `Object.defineProperty(process.env, key)` where value is dynamically calculated based on the current activation - also capture keys into a new context arg - change the main function invocation to send the context arg (as well as params) - generate a warning log for usages of process.env[key] (to signal to devs that they will need to migrate to the new signature) For java (and others), I think similar will work, although I'm not sure how simple it would be to intercept the env getter to inject a warning log. Each runtime will need to have some way to disambiguate the env var access in order to support concurrency without changing to use the new main function signature (`main(params, context)`), but additionally, each runtime should also change to support structured logging (activation id included with each log event), if it wants to support concurrency, so it should be considered to do BOTH of these at the same time, in each runtime.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
