To avoid scope creep. I implemented what Vadim proposed to make the runtime a bit more flexible, and allow the invoker to pass more env variables, so it up to the invoker how much or little to pass. These changes do not require changes on invoker code, or user aciton code, they are backward compatible
Out of scope: 1. changing the structure of the body for /run 2. splitting on /init and /run are good things to consider. 3. enhancing runtimes to allow more action signatures with context object Here are the proposed changes: *Update runtimes for Apache:* - Nodejs6, Nodejs8: https://github.com/apache/incubator-openwhisk-runtime-nodejs/compare/master...csantanapr:iam_flex_env_vars?expand=1 - Docker Skeleton: https://github.com/apache/incubator-openwhisk-runtime-docker/compare/master...csantanapr:iam_flex_env_vars?expand=1 - Python2, Phython3: https://github.com/apache/incubator-openwhisk-runtime-python/compare/master...csantanapr:iam_flex_env_vars?expand=1 - Swift3, Swift4: https://github.com/apache/incubator-openwhisk-runtime-swift/compare/master...csantanapr:iam_flex_env_vars?expand=1 - Java8 https://github.com/apache/incubator-openwhisk-runtime-java/compare/master...csantanapr:iam_flex_env_vars?expand=1 - Ruby https://github.com/apache/incubator-openwhisk-runtime-ruby/compare/master...csantanapr:iam_flex_env_vars?expand=1 - Ballerina https://github.com/apache/incubator-openwhisk-runtime-ballerina/compare/master...csantanapr:iam_flex_env_vars?expand=1 if I don't see a -1, I would submit PRs. -- Carlos On Mon, Aug 6, 2018 at 12:17 PM Rodric Rabbah <[email protected]> wrote: > > Ideally we need to remove most of our env vars from /run to /init, I > agree. > > But wouldn't it be a breaking change then? > > > > I don't think so - the first time a container is started, the values are > provided on init. > On run, the values that change would be provided (activation id, deadline). > > > > Coming back to my original question, I'm ok with leaving the env vars on > > the root level of the json object. I think Carlos already has PRs that > > could enable that functionality. > > > > Yes I think this is fine - would permit more vars to be passed on as env > vars as well in the future. > > -r >
