Re: Change the way the java runtime handles envirorment variable
This might a little bit aside from the discussion.
But one thing I want to mention on environment variables or context is, I
hope users can set up them differently than parameters.
One use case of environment variables could be supplying some secrets or
private data in shared-package actions.
If a user shares his package and an action inside of it requires some
secrets, the context arguments would help this work.
IIRC, there was a discussion on general permission enhancement, and what I
mentioned above can be achieved differently with enhanced permission
supports as well, but I just want to show an example that environment
variables can be used differently.
In this sense setting up `context` values just like `parameters` is not
that useful.
We need a different mechanism for users to set up them.
`Parameters` are already acting as a good way to provide inputs or data.
So if we decide to include the context as an invocation parameter, I hope
we can define a new mechanism for them rather than just setting up another
`parameters` and passing them at runtime.
Best regards
Dominic
2019년 5월 7일 (화) 오후 9:35, Rodric Rabbah 님이 작성:
> callback is gone in newer node versions in AWS lambda and you can return a
> promise which makes the difference between the lambda and openwhisk
> signature specific to context.
>
> Note that lambda is less uniform in signatures and models across
> languages. Annoyingly.
>
> -r
>
> > On May 7, 2019, at 8:28 AM, James Thomas wrote:
> >
> > I'd definitely prefer to see us have a more generic discussion on
> changing
> > all runtimes to provide the context as an invocation parameter, rather
> than
> > having per-runtime fixes. This doesn't affect the invokers AFAIK.
> >
> > Moving to providing a second `context` argument would have the advantage
> of
> > mirroring other serverless platforms, e.g. AWS Lambda.
> >
> > exports.*myHandler* = function(event, context, callback) {
> >*... function code*
> >callback(null, "some success message");
> > // or
> > // callback("some error type");
> > }
> >
> >
> >
> >> On Thu, 2 May 2019 at 18:11, Rodric Rabbah wrote:
> >>
> >> I agree that any such change doesn’t need to touch the invoker except to
> >> potentially remove one variable from the environment (api host).
> >>
> >>
> >> -r
> >>
> >>> On May 2, 2019, at 12:11 PM, Tyson Norris
> >> wrote:
> >>>
> >>> FWIW, I don't think of this as a huge change, meaning no change is
> >> required at invoker/controller. Rather it is just a convention for
> context
> >> value access within functions and function signature that is already
> unique
> >> to each language runtime, and requires possibly supporting 2 runtimes
> per
> >> language+convention while transitioning to the new convention. This
> >> convention is exposed to function developers so "replacing it" is not
> >> really an option, I think, but rather requires graceful deprecation and
> >> migration (with developers participation).
> >>>
> >>> e.g. for nodejs, the old convention used for signature and context is:
> >>> - function signature is ` (args)`
> >>> - context is `process.env.`
> >>>
> >>> New convention for signature and context is:
> >>> - function signature is ` (contextObject, args)`
> >>> - context is ` contextObject.`
> >>>
> >>> So you can feasibly:
> >>> * create a new runtime for nodejs that uses new convention
> >>> * add a separate kind for using the new runtime
> >>> * gradually phase out use of old kind (communication, deprecation, etc)
> >>>
> >>> I just want to throw this out there because I get the feeling whenever
> >> we discuss "context" that there is misconception around the need to
> change
> >> the invoker to support this. There is surely some parts of the
> >> invoker/action container protocol that may be further cleaned up to
> isolate
> >> static values (action name) from per-activation context (activation id),
> >> but I don't think that is required to start changing the conventions for
> >> function signature to include context as a separate object from
> activation
> >> params.
> >>>
> >>> Thanks
> >>> Tyson
> >>>
> >>>
> >>> On 5/2/19, 8:54 AM, "David P Grove" wrote:
> >>>
> >>>
> >>>
> >>> Rodric Rabbah wrote on 05/02/2019 11:05:35 AM:
>
> any existing java function that uses the environment variables would
> >> have
> to be modified.
> i would not change it - openwhisk has a uniform model across all the
> runtimes and this would start to diverge... i can be convinced but
> >>> instinct
> is to leave it alone.
>
> >>>
> >>> I think the change could be justified if it was part of a broader
> >> redesign
> >>> to enable concurrent activations in a runtime.
> >>> 1. pass in a context object instead of stashing
> >> activation-specific
> >>> params in the environment
> >>> 2. require proper structured logging
> >>>
> >>> --dave
> >>>
> >>>
> >>
> >
> >
> > --
> > Regards,
> > James Thomas
>
Re: Change the way the java runtime handles envirorment variable
callback is gone in newer node versions in AWS lambda and you can return a
promise which makes the difference between the lambda and openwhisk signature
specific to context.
Note that lambda is less uniform in signatures and models across languages.
Annoyingly.
-r
> On May 7, 2019, at 8:28 AM, James Thomas wrote:
>
> I'd definitely prefer to see us have a more generic discussion on changing
> all runtimes to provide the context as an invocation parameter, rather than
> having per-runtime fixes. This doesn't affect the invokers AFAIK.
>
> Moving to providing a second `context` argument would have the advantage of
> mirroring other serverless platforms, e.g. AWS Lambda.
>
> exports.*myHandler* = function(event, context, callback) {
>*... function code*
>callback(null, "some success message");
> // or
> // callback("some error type");
> }
>
>
>
>> On Thu, 2 May 2019 at 18:11, Rodric Rabbah wrote:
>>
>> I agree that any such change doesn’t need to touch the invoker except to
>> potentially remove one variable from the environment (api host).
>>
>>
>> -r
>>
>>> On May 2, 2019, at 12:11 PM, Tyson Norris
>> wrote:
>>>
>>> FWIW, I don't think of this as a huge change, meaning no change is
>> required at invoker/controller. Rather it is just a convention for context
>> value access within functions and function signature that is already unique
>> to each language runtime, and requires possibly supporting 2 runtimes per
>> language+convention while transitioning to the new convention. This
>> convention is exposed to function developers so "replacing it" is not
>> really an option, I think, but rather requires graceful deprecation and
>> migration (with developers participation).
>>>
>>> e.g. for nodejs, the old convention used for signature and context is:
>>> - function signature is ` (args)`
>>> - context is `process.env.`
>>>
>>> New convention for signature and context is:
>>> - function signature is ` (contextObject, args)`
>>> - context is ` contextObject.`
>>>
>>> So you can feasibly:
>>> * create a new runtime for nodejs that uses new convention
>>> * add a separate kind for using the new runtime
>>> * gradually phase out use of old kind (communication, deprecation, etc)
>>>
>>> I just want to throw this out there because I get the feeling whenever
>> we discuss "context" that there is misconception around the need to change
>> the invoker to support this. There is surely some parts of the
>> invoker/action container protocol that may be further cleaned up to isolate
>> static values (action name) from per-activation context (activation id),
>> but I don't think that is required to start changing the conventions for
>> function signature to include context as a separate object from activation
>> params.
>>>
>>> Thanks
>>> Tyson
>>>
>>>
>>> On 5/2/19, 8:54 AM, "David P Grove" wrote:
>>>
>>>
>>>
>>> Rodric Rabbah wrote on 05/02/2019 11:05:35 AM:
any existing java function that uses the environment variables would
>> have
to be modified.
i would not change it - openwhisk has a uniform model across all the
runtimes and this would start to diverge... i can be convinced but
>>> instinct
is to leave it alone.
>>>
>>> I think the change could be justified if it was part of a broader
>> redesign
>>> to enable concurrent activations in a runtime.
>>> 1. pass in a context object instead of stashing
>> activation-specific
>>> params in the environment
>>> 2. require proper structured logging
>>>
>>> --dave
>>>
>>>
>>
>
>
> --
> Regards,
> James Thomas
Re: Change the way the java runtime handles envirorment variable
I'd definitely prefer to see us have a more generic discussion on changing
all runtimes to provide the context as an invocation parameter, rather than
having per-runtime fixes. This doesn't affect the invokers AFAIK.
Moving to providing a second `context` argument would have the advantage of
mirroring other serverless platforms, e.g. AWS Lambda.
exports.*myHandler* = function(event, context, callback) {
*... function code*
callback(null, "some success message");
// or
// callback("some error type");
}
On Thu, 2 May 2019 at 18:11, Rodric Rabbah wrote:
> I agree that any such change doesn’t need to touch the invoker except to
> potentially remove one variable from the environment (api host).
>
>
> -r
>
> > On May 2, 2019, at 12:11 PM, Tyson Norris
> wrote:
> >
> > FWIW, I don't think of this as a huge change, meaning no change is
> required at invoker/controller. Rather it is just a convention for context
> value access within functions and function signature that is already unique
> to each language runtime, and requires possibly supporting 2 runtimes per
> language+convention while transitioning to the new convention. This
> convention is exposed to function developers so "replacing it" is not
> really an option, I think, but rather requires graceful deprecation and
> migration (with developers participation).
> >
> > e.g. for nodejs, the old convention used for signature and context is:
> > - function signature is ` (args)`
> > - context is `process.env.`
> >
> > New convention for signature and context is:
> > - function signature is ` (contextObject, args)`
> > - context is ` contextObject.`
> >
> > So you can feasibly:
> > * create a new runtime for nodejs that uses new convention
> > * add a separate kind for using the new runtime
> > * gradually phase out use of old kind (communication, deprecation, etc)
> >
> > I just want to throw this out there because I get the feeling whenever
> we discuss "context" that there is misconception around the need to change
> the invoker to support this. There is surely some parts of the
> invoker/action container protocol that may be further cleaned up to isolate
> static values (action name) from per-activation context (activation id),
> but I don't think that is required to start changing the conventions for
> function signature to include context as a separate object from activation
> params.
> >
> > Thanks
> > Tyson
> >
> >
> > On 5/2/19, 8:54 AM, "David P Grove" wrote:
> >
> >
> >
> >Rodric Rabbah wrote on 05/02/2019 11:05:35 AM:
> >>
> >> any existing java function that uses the environment variables would
> have
> >> to be modified.
> >> i would not change it - openwhisk has a uniform model across all the
> >> runtimes and this would start to diverge... i can be convinced but
> >instinct
> >> is to leave it alone.
> >>
> >
> >I think the change could be justified if it was part of a broader
> redesign
> >to enable concurrent activations in a runtime.
> >1. pass in a context object instead of stashing
> activation-specific
> >params in the environment
> >2. require proper structured logging
> >
> >--dave
> >
> >
>
--
Regards,
James Thomas
Re: Change the way the java runtime handles envirorment variable
I agree that any such change doesn’t need to touch the invoker except to potentially remove one variable from the environment (api host). -r > On May 2, 2019, at 12:11 PM, Tyson Norris wrote: > > FWIW, I don't think of this as a huge change, meaning no change is required > at invoker/controller. Rather it is just a convention for context value > access within functions and function signature that is already unique to each > language runtime, and requires possibly supporting 2 runtimes per > language+convention while transitioning to the new convention. This > convention is exposed to function developers so "replacing it" is not really > an option, I think, but rather requires graceful deprecation and migration > (with developers participation). > > e.g. for nodejs, the old convention used for signature and context is: > - function signature is ` (args)` > - context is `process.env.` > > New convention for signature and context is: > - function signature is ` (contextObject, args)` > - context is ` contextObject.` > > So you can feasibly: > * create a new runtime for nodejs that uses new convention > * add a separate kind for using the new runtime > * gradually phase out use of old kind (communication, deprecation, etc) > > I just want to throw this out there because I get the feeling whenever we > discuss "context" that there is misconception around the need to change the > invoker to support this. There is surely some parts of the invoker/action > container protocol that may be further cleaned up to isolate static values > (action name) from per-activation context (activation id), but I don't think > that is required to start changing the conventions for function signature to > include context as a separate object from activation params. > > Thanks > Tyson > > > On 5/2/19, 8:54 AM, "David P Grove" wrote: > > > >Rodric Rabbah wrote on 05/02/2019 11:05:35 AM: >> >> any existing java function that uses the environment variables would have >> to be modified. >> i would not change it - openwhisk has a uniform model across all the >> runtimes and this would start to diverge... i can be convinced but >instinct >> is to leave it alone. >> > >I think the change could be justified if it was part of a broader redesign >to enable concurrent activations in a runtime. >1. pass in a context object instead of stashing activation-specific >params in the environment >2. require proper structured logging > >--dave > >
Re: Change the way the java runtime handles envirorment variable
FWIW, I don't think of this as a huge change, meaning no change is required at invoker/controller. Rather it is just a convention for context value access within functions and function signature that is already unique to each language runtime, and requires possibly supporting 2 runtimes per language+convention while transitioning to the new convention. This convention is exposed to function developers so "replacing it" is not really an option, I think, but rather requires graceful deprecation and migration (with developers participation). e.g. for nodejs, the old convention used for signature and context is: - function signature is ` (args)` - context is `process.env.` New convention for signature and context is: - function signature is ` (contextObject, args)` - context is ` contextObject.` So you can feasibly: * create a new runtime for nodejs that uses new convention * add a separate kind for using the new runtime * gradually phase out use of old kind (communication, deprecation, etc) I just want to throw this out there because I get the feeling whenever we discuss "context" that there is misconception around the need to change the invoker to support this. There is surely some parts of the invoker/action container protocol that may be further cleaned up to isolate static values (action name) from per-activation context (activation id), but I don't think that is required to start changing the conventions for function signature to include context as a separate object from activation params. Thanks Tyson On 5/2/19, 8:54 AM, "David P Grove" wrote: Rodric Rabbah wrote on 05/02/2019 11:05:35 AM: > > any existing java function that uses the environment variables would have > to be modified. > i would not change it - openwhisk has a uniform model across all the > runtimes and this would start to diverge... i can be convinced but instinct > is to leave it alone. > I think the change could be justified if it was part of a broader redesign to enable concurrent activations in a runtime. 1. pass in a context object instead of stashing activation-specific params in the environment 2. require proper structured logging --dave
Re: Change the way the java runtime handles envirorment variable
Rodric Rabbah wrote on 05/02/2019 11:05:35 AM: > > any existing java function that uses the environment variables would have > to be modified. > i would not change it - openwhisk has a uniform model across all the > runtimes and this would start to diverge... i can be convinced but instinct > is to leave it alone. > I think the change could be justified if it was part of a broader redesign to enable concurrent activations in a runtime. 1. pass in a context object instead of stashing activation-specific params in the environment 2. require proper structured logging --dave
Change the way the java runtime handles envirorment variable
Hello all,
I am in the process of writing a new ActionLoop based runtime for Java, I have
a prototype and it is 10times faster so it is worth the effort.
I am trying to make it backward compatible with the existing.
In the process I found the way the current runtime sets environment variables.
Since it is well known it is not possible in Java (everyone uses
System.properties as a replacement), this is what the current runtime does to
change them:
---
private static void augmentEnv(Map newEnv) {
try {
for (Class cl : Collections.class.getDeclaredClasses()) {
if
("java.util.Collections$UnmodifiableMap".equals(cl.getName())) {
Field field = cl.getDeclaredField("m");
field.setAccessible(true);
Object obj = field.get(System.getenv());
Map map = (Map) obj;
map.putAll(newEnv);
}
}
} catch (Exception e) {}
}
---
Basically, since the Env is an unmodifiable map, looks like it HACKS it with
reflection, it finding a private field, forcing it to be accessible and
modifying it.
An hack from StackOverflow:
https://stackoverflow.com/questions/318239/how-do-i-set-environment-variables-from-java
My stomach cannot stand the disgust of this horror. What will happen if in the
new runtime I use System properties to pass environment variables instead (as
it is the common practice in Java)?
Will huge codebases break and large companies will be sued for daring to break
backward compatibility?
--
Michele Sciabarra
mich...@sciabarra.com
