Re: System env vars in user containers
RE “context” object it’s interesting to observe what other FaaS providers do in that regard. See, AWS [1], Azure [2], and Google [3]. If we want to later support (a) concurrency AND (b) “raw” requests ( as in No Objects, imagine the “raw” param being a JPEG image ) then the added “context” param seem to enable this functionality. [1] - https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-handler.html [2] - https://docs.microsoft.com/en-us/azure/azure-functions/functions-triggers-bindings [3] - https://cloud.google.com/functions/docs/concepts/events-triggers On Tue, Aug 7, 2018 at 1:25 AM Vadim Raskin wrote: > Right, invoker already has the changes provided by the Entitlement spi. > Additional variables are provided via `authEnvironment`val in the > ContainerProxy.scala. > Just want to point out that the new variables will be only available for > the downstream implementations of the Entitlement SPI, e.g. IBM Functions. > > regards, > Vadim. > > On Mon, Aug 6, 2018 at 10:14 PM Carlos Santana > wrote: > > > There are no changes required to the invoker code to enable this, this is > > already supported via SPI from what I understand, but Vadim can clarify > > > > -- Carlos > > > > On Mon, Aug 6, 2018 at 4:11 PM Carlos Santana > > wrote: > > > > > The runtime changes will allow a downstream like IBM Functions to > > > implement the authentication and entitlement SPI already discussed in > the > > > mailing list by Martin, the controller will pass IAM (Identity and > Access > > > Management) data about the namespace to the invoker, and the invoker > will > > > pass this data to the runtimes as extra environment variables. > > > > > > -- Carlos > > > > > > > > > On Mon, Aug 6, 2018 at 2:22 PM Rodric Rabbah wrote: > > > > > >> > > >> > 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. > > >> > > >> It wasn’t but without invoker changes this in itself isn’t very > useful. > > >> You are right. > > >> > > >> -r > > > > > > > > >
Re: System env vars in user containers
Right, invoker already has the changes provided by the Entitlement spi. Additional variables are provided via `authEnvironment`val in the ContainerProxy.scala. Just want to point out that the new variables will be only available for the downstream implementations of the Entitlement SPI, e.g. IBM Functions. regards, Vadim. On Mon, Aug 6, 2018 at 10:14 PM Carlos Santana wrote: > There are no changes required to the invoker code to enable this, this is > already supported via SPI from what I understand, but Vadim can clarify > > -- Carlos > > On Mon, Aug 6, 2018 at 4:11 PM Carlos Santana > wrote: > > > The runtime changes will allow a downstream like IBM Functions to > > implement the authentication and entitlement SPI already discussed in the > > mailing list by Martin, the controller will pass IAM (Identity and Access > > Management) data about the namespace to the invoker, and the invoker will > > pass this data to the runtimes as extra environment variables. > > > > -- Carlos > > > > > > On Mon, Aug 6, 2018 at 2:22 PM Rodric Rabbah wrote: > > > >> > >> > 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. > >> > >> It wasn’t but without invoker changes this in itself isn’t very useful. > >> You are right. > >> > >> -r > > > > >
Re: System env vars in user containers
There are no changes required to the invoker code to enable this, this is already supported via SPI from what I understand, but Vadim can clarify -- Carlos On Mon, Aug 6, 2018 at 4:11 PM Carlos Santana wrote: > The runtime changes will allow a downstream like IBM Functions to > implement the authentication and entitlement SPI already discussed in the > mailing list by Martin, the controller will pass IAM (Identity and Access > Management) data about the namespace to the invoker, and the invoker will > pass this data to the runtimes as extra environment variables. > > -- Carlos > > > On Mon, Aug 6, 2018 at 2:22 PM Rodric Rabbah wrote: > >> >> > 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. >> >> It wasn’t but without invoker changes this in itself isn’t very useful. >> You are right. >> >> -r > >
Re: System env vars in user containers
The runtime changes will allow a downstream like IBM Functions to implement the authentication and entitlement SPI already discussed in the mailing list by Martin, the controller will pass IAM (Identity and Access Management) data about the namespace to the invoker, and the invoker will pass this data to the runtimes as extra environment variables. -- Carlos On Mon, Aug 6, 2018 at 2:22 PM Rodric Rabbah wrote: > > > 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. > > It wasn’t but without invoker changes this in itself isn’t very useful. > You are right. > > -r
Re: System env vars in user containers
> 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. It wasn’t but without invoker changes this in itself isn’t very useful. You are right. -r
Re: System env vars in user containers
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 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 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 >>
Re: System env vars in user containers
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 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 >
Re: System env vars in user containers
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 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
Re: System env vars in user containers
> 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
Re: System env vars in user containers
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? 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. regards, Vadim. On Mon, Aug 6, 2018 at 11:35 AM Chetan Mehrotra wrote: > So far I was only thinking to pass in state like we do currently as json > string. But yes we can improvise that and pass in a proper language > specific instance with defined interface. Also in addition to state it can > have some methods attached to it. > > This would also reduce the slight overhead (and boilerplate logic) of json > marshalling and unmarshalling. > > Chetan Mehrotra > > > On Mon, Aug 6, 2018 at 2:34 PM Markus Thömmes > wrote: > > > I guess this is the famous "context" object, that some other platforms > > use in their function signature? @Chetan is that what you're referring > > to in option 2? > > Am Mo., 6. Aug. 2018 um 10:58 Uhr schrieb Chetan Mehrotra > > : > > > > > > > What are you thinking as an alternarive? > > > > > > There can be 2 ways > > > > > > 1. Make them part of request json itself say by placing them under > > > `_ow_env` key > > > 2. Or introduce a new explicit env param to the run method call > > > > > > #1 would be compatible. We can also introduce some convention for such > > > system generated values like start with '__' or '__ow_' etc > to > > > avoid collision in future for such changes > > > > > > Chetan Mehrotra > > > > > > > > > On Mon, Aug 6, 2018 at 2:14 PM Rodric Rabbah wrote: > > > > > > > > > > > > Should we reduce dependency on env variable to communicate such > > state? > > > > > > > > Oy. That’s right the activation id and deadline will conflict. What > are > > > > you thinking as an alternarive? > > > > > > > > -r > > >
Re: System env vars in user containers
So far I was only thinking to pass in state like we do currently as json string. But yes we can improvise that and pass in a proper language specific instance with defined interface. Also in addition to state it can have some methods attached to it. This would also reduce the slight overhead (and boilerplate logic) of json marshalling and unmarshalling. Chetan Mehrotra On Mon, Aug 6, 2018 at 2:34 PM Markus Thömmes wrote: > I guess this is the famous "context" object, that some other platforms > use in their function signature? @Chetan is that what you're referring > to in option 2? > Am Mo., 6. Aug. 2018 um 10:58 Uhr schrieb Chetan Mehrotra > : > > > > > What are you thinking as an alternarive? > > > > There can be 2 ways > > > > 1. Make them part of request json itself say by placing them under > > `_ow_env` key > > 2. Or introduce a new explicit env param to the run method call > > > > #1 would be compatible. We can also introduce some convention for such > > system generated values like start with '__' or '__ow_' etc to > > avoid collision in future for such changes > > > > Chetan Mehrotra > > > > > > On Mon, Aug 6, 2018 at 2:14 PM Rodric Rabbah wrote: > > > > > > > > > Should we reduce dependency on env variable to communicate such > state? > > > > > > Oy. That’s right the activation id and deadline will conflict. What are > > > you thinking as an alternarive? > > > > > > -r >
Re: System env vars in user containers
I guess this is the famous "context" object, that some other platforms use in their function signature? @Chetan is that what you're referring to in option 2? Am Mo., 6. Aug. 2018 um 10:58 Uhr schrieb Chetan Mehrotra : > > > What are you thinking as an alternarive? > > There can be 2 ways > > 1. Make them part of request json itself say by placing them under > `_ow_env` key > 2. Or introduce a new explicit env param to the run method call > > #1 would be compatible. We can also introduce some convention for such > system generated values like start with '__' or '__ow_' etc to > avoid collision in future for such changes > > Chetan Mehrotra > > > On Mon, Aug 6, 2018 at 2:14 PM Rodric Rabbah wrote: > > > > > > Should we reduce dependency on env variable to communicate such state? > > > > Oy. That’s right the activation id and deadline will conflict. What are > > you thinking as an alternarive? > > > > -r
Re: System env vars in user containers
> What are you thinking as an alternarive? There can be 2 ways 1. Make them part of request json itself say by placing them under `_ow_env` key 2. Or introduce a new explicit env param to the run method call #1 would be compatible. We can also introduce some convention for such system generated values like start with '__' or '__ow_' etc to avoid collision in future for such changes Chetan Mehrotra On Mon, Aug 6, 2018 at 2:14 PM Rodric Rabbah wrote: > > > Should we reduce dependency on env variable to communicate such state? > > Oy. That’s right the activation id and deadline will conflict. What are > you thinking as an alternarive? > > -r
Re: System env vars in user containers
> Should we reduce dependency on env variable to communicate such state? Oy. That’s right the activation id and deadline will conflict. What are you thinking as an alternarive? -r
Re: System env vars in user containers
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
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 <
> raskinva...@gmail.com>:
> >
> > 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
>
Re: System env vars in user containers
Ah yeah! Dividing /init and /run time provided parameters makes a lot of sense to minimize potential performance impact! +1 on that. Am Mo., 6. Aug. 2018 um 10:37 Uhr schrieb Rodric Rabbah : > > +1 for backward compatibility. > > I would also provide the env vars at init time. (Currently they’re available > at run time). > > The api host is provided as a container env var is partly historical and > partly because it’s the same for all containers so it was remained factored > out when we added the rest of the context vars. > > -r
Re: System env vars in user containers
+1 for backward compatibility. I would also provide the env vars at init time. (Currently they’re available at run time). The api host is provided as a container env var is partly historical and partly because it’s the same for all containers so it was remained factored out when we added the rest of the context vars. -r
Re: System env vars in user containers
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 :
>
> 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
System env vars in user containers
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
