So what are the invoker changes that will leverage these runtime changes? I’m not sure that context was part of the thread yet, sorry if it was.
> On Aug 6, 2018, at 10:52 AM, Carlos Santana <csantan...@gmail.com> wrote: > > 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-openwhisk-runtime-nodejs%2Fcompare%2Fmaster...csantanapr%3Aiam_flex_env_vars%3Fexpand%3D1&data=02%7C01%7Ctnorris%40adobe.com%7Cac6ed4689003431a40c108d5fbc56205%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636691747561463947&sdata=sR1qBnSxkKTPzz%2B4Ijr%2ByVyS9LaxVaZ1lCD%2BXJthjAw%3D&reserved=0 > - Docker Skeleton: > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-openwhisk-runtime-docker%2Fcompare%2Fmaster...csantanapr%3Aiam_flex_env_vars%3Fexpand%3D1&data=02%7C01%7Ctnorris%40adobe.com%7Cac6ed4689003431a40c108d5fbc56205%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636691747561463947&sdata=NMTxeBqQGUiU4O%2BWlxiTiFN6gMS1lumEdUhxCy1Jz6o%3D&reserved=0 > - Python2, Phython3: > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-openwhisk-runtime-python%2Fcompare%2Fmaster...csantanapr%3Aiam_flex_env_vars%3Fexpand%3D1&data=02%7C01%7Ctnorris%40adobe.com%7Cac6ed4689003431a40c108d5fbc56205%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636691747561463947&sdata=DEYgFy3VKXUawsSuBhYBllMwyDY8IoMAiziaVDXEblY%3D&reserved=0 > - Swift3, Swift4: > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-openwhisk-runtime-swift%2Fcompare%2Fmaster...csantanapr%3Aiam_flex_env_vars%3Fexpand%3D1&data=02%7C01%7Ctnorris%40adobe.com%7Cac6ed4689003431a40c108d5fbc56205%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636691747561463947&sdata=3CMhx2KpIDuqC9%2BAFx%2FSi8grfT5BVxhKIvucvsQFIyQ%3D&reserved=0 > - Java8 > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-openwhisk-runtime-java%2Fcompare%2Fmaster...csantanapr%3Aiam_flex_env_vars%3Fexpand%3D1&data=02%7C01%7Ctnorris%40adobe.com%7Cac6ed4689003431a40c108d5fbc56205%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636691747561463947&sdata=fYf81Arf23oLX15vQRfg97C8hXkvtXS8wFAHDCPcU2Q%3D&reserved=0 > - Ruby > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-openwhisk-runtime-ruby%2Fcompare%2Fmaster...csantanapr%3Aiam_flex_env_vars%3Fexpand%3D1&data=02%7C01%7Ctnorris%40adobe.com%7Cac6ed4689003431a40c108d5fbc56205%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636691747561463947&sdata=HAcFWm2Oa5gV1GGwvpuW8ZnL1VYcWAc5Ubk96WXF3Pc%3D&reserved=0 > - Ballerina > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-openwhisk-runtime-ballerina%2Fcompare%2Fmaster...csantanapr%3Aiam_flex_env_vars%3Fexpand%3D1&data=02%7C01%7Ctnorris%40adobe.com%7Cac6ed4689003431a40c108d5fbc56205%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636691747561463947&sdata=FmYWGorcluPQMr3iRFbzq9cG4Mx8V2phN3rh328lJ7c%3D&reserved=0 > > if I don't see a -1, I would submit PRs. > > -- Carlos > > > On Mon, Aug 6, 2018 at 12:17 PM Rodric Rabbah <rod...@gmail.com> 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 >>
