openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chetan Mehrotra <chetan.mehro...@gmail.com>
Subject Re: System env vars in user containers
Date Mon, 06 Aug 2018 08:41:23 GMT
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 <markusthoemmes@apache.org>
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 <
> raskinvadim@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message