Other than parsing JSON (and compatibility), does setting env vars instead of propagating a JSON object into the /run handler give any benefit?
Since any runtime that wants to support concurrency won’t leverage any (or at least most, except “action name”?) vars during /init, and won’t leverage env vars during /run, I would hesitate to add “more env vars”, but I’m not sure the use case or the PRs being mentioned. I would keep it simpler and: - allow containers to continue using env vars as is for compatibility, but skip this processing if concurrency is enabled (I can check into this for nodejs container) - containers that support concurrency will need to just pass the JSON object (e.g. the req body, sans "value") as the “context” to /run This of course changes the sig from main(params) to main(params, context), but this would not impact compatibility afaik. Alternatively, as Chetan mentions, we can merge these to a single arg with “special keys”. I don’t have a strong opinion on which of these is implemented, just that env vars won’t be usable in concurrency cases (just like other forms of “global vars”). Thanks Tyson > On Aug 6, 2018, at 9:17 AM, 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
