You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwhisk.apache.org by Dragos Dascalita Haut <dd...@adobe.com> on 2017/01/07 01:04:07 UTC
Passing a context object to actions
Hi,
These days I've been doing some work on creating an OpenWhisk action directly from a GitHub repo - issue link [1] ; initial implementation [2] . After successfully deploying a "hello-world" action - [3] I thought about updating the message with some information from an OAuth token. I've used the API Gateway to decorate the request with a "context" object. To achieve this I had to merge the context with the actual event payload. I've posted the snippet of the API Gateway code at [4] in a gist. Things are working fine and here is a sample of a response from the action; note the "context" object which was added by the API Gateway.
{
"payload": "Hello, 1FF62BDC53C3662B from branch-1 !",
"event": {
"context": {
"identity": {
"user_id": "1FF62BDC53C3662B",
"client_id": "demo_app",
"scope": "openid,avatar"
}
}
}
}
As a result of this experience I've learned a few things out of which the most important one that I'd like to open a discussion here on the list is: the mechanism to pass a context to an action.
At the moment the only way is to decorate the event with extra fields and I see a few drawbacks to this approach:
* The fact that we need to unpack the request body and change it has an impact on performance
* If we want to send binary payloads in a special format, the API Gateway or some other process in the middle has to know how to decode/encode that payload/Content-Type. So we're limited to what these intermediary processes know.
The same thing happens with default action parameters; they get merged with the event. Basically besides the event itself there's no other way to configure the action with extra params or pass it a context.
I'd like to get your feedback to see if we're ok to enhance the existing mechanism.
As an example, AWS Lambda allows a similar mechanism to pass a "context" to a function. See [5]. Clients can provide a custom "clientContext" object . Besides this object, the AWS API Gateway also adds its own fields into the "context" object; see [6].
If we want, we could take a similar approach. The way it works in AWS is through headers. For instance the "clientContext" is passed as a Base64 JSON-encoded header.
In OpenWhisk actions the main method signature would allow 2 params instead of 1 (as it is today) and it could look like:
function main(event, context)
The clientContext would be accessible as:
context.clientContext
And context.identity.* would be something reserved for the OpenWhisk API Gateway to populate and it could also be based on special headers like "X-GW-Identity".
What I like about this approach with Headers is that no intermediary process needs to understand the body of the request; we could also support multiple content types easier as well.
WDYT ?
Thanks,
dragos dascalita haut | project lead, software development | adobe cloud platform
[1] - https://github.com/openwhisk/openwhisk/issues/1537
[2] - https://github.com/ddragosd/openwhisk-github-deployer
[3] - https://github.com/ddragosd/openwhisk-hello-package/blob/branch-1/src/greeting.js
[4] - https://gist.github.com/ddragosd/3afd5d8678e5dbda48b943a1125aad0c#file-zcloudfront-conf-L71-L93
[5] - http://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_RequestSyntax
[6] - http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html#context-variable-reference
Re: Passing a context object to actions
Posted by Rodric Rabbah <ro...@gmail.com>.
The proposal is not yet implemented. Please add to the issue.
Parameters are not allowed on sequences deliberately - until we resolve the scoping issue (in case we need to migrate schemes for example).
-r
Re: Passing a context object to actions
Posted by Michael Marth <mm...@adobe.com>.
Hi Rodric,
Thanks for passing the link! Very interesting.
IIUC the discussion then the consensus for that particular issue is summarised in [1], but this is not implemented, yet. Is this correct?
Also, I have a question about the solution in [1]
(Happy to post it into that issue, if that’s the better place to have the discussion)
I wonder why the parameter *values* are show up in the sequence definition at *creation* time of the sequence in
“wsk action create sequence S —action A1 P11 V11 P12 V12 —action A2 P21 V21 P22 V23"
That seems to not allow for setting parameter values at invocation time - or do I misinterpret the proposal?
Thanks!
Michael
[1] https://github.com/openwhisk/openwhisk/issues/116#issuecomment-229976950
On 17/01/17 13:55, "Rodric Rabbah" <ro...@gmail.com> wrote:
>You're raising a different issue that is orthogonal to final/immutable parameters. For sequences and parameter scoping see this discussion: https://github.com/openwhisk/openwhisk/issues/116
>
>-r
>
>> On Jan 17, 2017, at 7:47 AM, Michael Marth <mm...@adobe.com> wrote:
>>
>> Hi Rodric, all,
>>
>> Final parameters sound nice. I think they probably solve the challenge that Dragos outlined originally.
>> However, I am not sure if they are the ideal solution for OW in general.
>>
>> Let me re-cap the issue:
>> * assume OW deployments where an API gateway authenticates incoming requests and sets e.g. the userId as a header that gets forwarded to the action
>> * the subsequently invoked action’s code wants to read that header (userId)
>> * if a sequence was invoked by the request each action in the sequence must be able to read that header (and be sure that it has not been tampered with by previous actions in the sequence)
>>
>> IIUC final parameters solve this challenge provided that all involved parties (gateway deployment and all actions in the sequence) agree on the name and semantics of that header containing the userId. That is not a problem as long as these actions always get deployed into one particular OW deployment. However, I think it breaks compatibility of actions when moved between different OW deployments.
>> I see the downsides of changing the method signature that you mentioned, Rodric. Maybe there’s another way? (like environment variables that can be read from the function or globally accessible objects, etc)
>> Is this already solved in Bluemix?
>>
>> Cheers
>> Michael
>>
>>
>>
>>> On 11/01/17 23:17, "Rodric Rabbah" <ro...@gmail.com> wrote:
>>>
>>> +1 to @sjfink: passing large objects inline should probably be adopted as
>>> an anti-pattern.
>>>
>>>> I'm also adding an extra thought to our thread: if we want to communicate
>>> a "user_id" and "app_id" to the actions, but any action can edit the
>>> incoming event, how would we make sure that some important fields like
>>> these ones can't be overwritten by other actions in a sequence and they can
>>> be securely passed through and trusted ?
>>>
>>> @ddascal <dd...@adobe.com> I just opened this PR that prototypes the idea
>>> of "final" parameters that might be applicable. This came up in discussion
>>> with Steve where he suggested that any defined parameter (if it has a
>>> value) should be considered final. This would mean that parameters on a
>>> package that have a default value cannot be overridden by a binding or an
>>> action in the package. I implemented a variant of this [1] that applies to
>>> certain openwhisk actions where an action may carry a "final" annotation
>>> which prevents an incoming request from overriding any of its predefined
>>> parameters.
>>>
>>> In a more general perspective, we can give up on default parameters in
>>> favor of final parameters everywhere. Or a compromise where parameters may
>>> have defaults and may be overriden from package to binding to action but
>>> not from invoke time parameters (as in the pull request).
>>>
>>> -r
>>>
>>> [1] https://github.com/openwhisk/openwhisk/pull/1710
Re: Passing a context object to actions
Posted by Rodric Rabbah <ro...@gmail.com>.
You're raising a different issue that is orthogonal to final/immutable parameters. For sequences and parameter scoping see this discussion: https://github.com/openwhisk/openwhisk/issues/116
-r
> On Jan 17, 2017, at 7:47 AM, Michael Marth <mm...@adobe.com> wrote:
>
> Hi Rodric, all,
>
> Final parameters sound nice. I think they probably solve the challenge that Dragos outlined originally.
> However, I am not sure if they are the ideal solution for OW in general.
>
> Let me re-cap the issue:
> * assume OW deployments where an API gateway authenticates incoming requests and sets e.g. the userId as a header that gets forwarded to the action
> * the subsequently invoked action’s code wants to read that header (userId)
> * if a sequence was invoked by the request each action in the sequence must be able to read that header (and be sure that it has not been tampered with by previous actions in the sequence)
>
> IIUC final parameters solve this challenge provided that all involved parties (gateway deployment and all actions in the sequence) agree on the name and semantics of that header containing the userId. That is not a problem as long as these actions always get deployed into one particular OW deployment. However, I think it breaks compatibility of actions when moved between different OW deployments.
> I see the downsides of changing the method signature that you mentioned, Rodric. Maybe there’s another way? (like environment variables that can be read from the function or globally accessible objects, etc)
> Is this already solved in Bluemix?
>
> Cheers
> Michael
>
>
>
>> On 11/01/17 23:17, "Rodric Rabbah" <ro...@gmail.com> wrote:
>>
>> +1 to @sjfink: passing large objects inline should probably be adopted as
>> an anti-pattern.
>>
>>> I'm also adding an extra thought to our thread: if we want to communicate
>> a "user_id" and "app_id" to the actions, but any action can edit the
>> incoming event, how would we make sure that some important fields like
>> these ones can't be overwritten by other actions in a sequence and they can
>> be securely passed through and trusted ?
>>
>> @ddascal <dd...@adobe.com> I just opened this PR that prototypes the idea
>> of "final" parameters that might be applicable. This came up in discussion
>> with Steve where he suggested that any defined parameter (if it has a
>> value) should be considered final. This would mean that parameters on a
>> package that have a default value cannot be overridden by a binding or an
>> action in the package. I implemented a variant of this [1] that applies to
>> certain openwhisk actions where an action may carry a "final" annotation
>> which prevents an incoming request from overriding any of its predefined
>> parameters.
>>
>> In a more general perspective, we can give up on default parameters in
>> favor of final parameters everywhere. Or a compromise where parameters may
>> have defaults and may be overriden from package to binding to action but
>> not from invoke time parameters (as in the pull request).
>>
>> -r
>>
>> [1] https://github.com/openwhisk/openwhisk/pull/1710
Re: Passing a context object to actions
Posted by Michael Marth <mm...@adobe.com>.
Hi Rodric, all,
Final parameters sound nice. I think they probably solve the challenge that Dragos outlined originally.
However, I am not sure if they are the ideal solution for OW in general.
Let me re-cap the issue:
* assume OW deployments where an API gateway authenticates incoming requests and sets e.g. the userId as a header that gets forwarded to the action
* the subsequently invoked action’s code wants to read that header (userId)
* if a sequence was invoked by the request each action in the sequence must be able to read that header (and be sure that it has not been tampered with by previous actions in the sequence)
IIUC final parameters solve this challenge provided that all involved parties (gateway deployment and all actions in the sequence) agree on the name and semantics of that header containing the userId. That is not a problem as long as these actions always get deployed into one particular OW deployment. However, I think it breaks compatibility of actions when moved between different OW deployments.
I see the downsides of changing the method signature that you mentioned, Rodric. Maybe there’s another way? (like environment variables that can be read from the function or globally accessible objects, etc)
Is this already solved in Bluemix?
Cheers
Michael
On 11/01/17 23:17, "Rodric Rabbah" <ro...@gmail.com> wrote:
>+1 to @sjfink: passing large objects inline should probably be adopted as
>an anti-pattern.
>
>> I'm also adding an extra thought to our thread: if we want to communicate
>a "user_id" and "app_id" to the actions, but any action can edit the
>incoming event, how would we make sure that some important fields like
>these ones can't be overwritten by other actions in a sequence and they can
>be securely passed through and trusted ?
>
>@ddascal <dd...@adobe.com> I just opened this PR that prototypes the idea
>of "final" parameters that might be applicable. This came up in discussion
>with Steve where he suggested that any defined parameter (if it has a
>value) should be considered final. This would mean that parameters on a
>package that have a default value cannot be overridden by a binding or an
>action in the package. I implemented a variant of this [1] that applies to
>certain openwhisk actions where an action may carry a "final" annotation
>which prevents an incoming request from overriding any of its predefined
>parameters.
>
>In a more general perspective, we can give up on default parameters in
>favor of final parameters everywhere. Or a compromise where parameters may
>have defaults and may be overriden from package to binding to action but
>not from invoke time parameters (as in the pull request).
>
>-r
>
>[1] https://github.com/openwhisk/openwhisk/pull/1710
Re: Passing a context object to actions
Posted by Rodric Rabbah <ro...@gmail.com>.
+1 to @sjfink: passing large objects inline should probably be adopted as
an anti-pattern.
> I'm also adding an extra thought to our thread: if we want to communicate
a "user_id" and "app_id" to the actions, but any action can edit the
incoming event, how would we make sure that some important fields like
these ones can't be overwritten by other actions in a sequence and they can
be securely passed through and trusted ?
@ddascal <dd...@adobe.com> I just opened this PR that prototypes the idea
of "final" parameters that might be applicable. This came up in discussion
with Steve where he suggested that any defined parameter (if it has a
value) should be considered final. This would mean that parameters on a
package that have a default value cannot be overridden by a binding or an
action in the package. I implemented a variant of this [1] that applies to
certain openwhisk actions where an action may carry a "final" annotation
which prevents an incoming request from overriding any of its predefined
parameters.
In a more general perspective, we can give up on default parameters in
favor of final parameters everywhere. Or a compromise where parameters may
have defaults and may be overriden from package to binding to action but
not from invoke time parameters (as in the pull request).
-r
[1] https://github.com/openwhisk/openwhisk/pull/1710
Re: Passing a context object to actions
Posted by Dragos Dascalita Haut <dd...@adobe.com>.
"...For now, the recommended practice is to NOT pass large binary objects by value, but instead to pass a reference..."
+1 to this.
"...One idea for the future is to consider having a source-independent input stream library for use in whisk actions..."
It would be great to have this in mind for any further work ( API Gateway included) making sure the code doesn't restrict this.
Are we aware of any use-case requiring that Openwhisk Controller, Invoker or another component (apart from the actions themselves) to "understand"/decode the payload ?
Thanks,
dragos
________________________________
From: Stephen Fink <fi...@gmail.com>
Sent: Wednesday, January 11, 2017 2:03:11 PM
To: dev@openwhisk.apache.org
Subject: Re: Passing a context object to actions
Regarding binary objects:
For now, the recommended practice is to NOT pass large binary objects by value, but instead to pass a reference, such as an object identifier to an object store. The action code can then read or stream the data using an appropriate library.
I don’t see a great reason to imagine passing large objects by value. Feel free to argue otherwise if you disagree.
One idea for the future is to consider having a source-independent input stream library for use in whisk actions, which is configured by the whisk runtime to delegate to the appropriate mechanisms for streaming arbitrary binary data. This could be done entirely at user-level as a prototype, I think, without any changes to the core runtime.
> On Jan 9, 2017, at 2:02 PM, Dragos Dascalita Haut <dd...@adobe.com> wrote:
>
>
Re: Passing a context object to actions
Posted by Stephen Fink <fi...@gmail.com>.
Regarding binary objects:
For now, the recommended practice is to NOT pass large binary objects by value, but instead to pass a reference, such as an object identifier to an object store. The action code can then read or stream the data using an appropriate library.
I don’t see a great reason to imagine passing large objects by value. Feel free to argue otherwise if you disagree.
One idea for the future is to consider having a source-independent input stream library for use in whisk actions, which is configured by the whisk runtime to delegate to the appropriate mechanisms for streaming arbitrary binary data. This could be done entirely at user-level as a prototype, I think, without any changes to the core runtime.
> On Jan 9, 2017, at 2:02 PM, Dragos Dascalita Haut <dd...@adobe.com> wrote:
>
>
Re: Passing a context object to actions
Posted by Dragos Dascalita Haut <dd...@adobe.com>.
Rodric, thanks for sharing more info. I've been thinking at it over the weekend.
I'm reading in the Gist comment that the idea is to do:
1. json_data.event = data;
2. json_data.context = ...
I'm wondering what do we do when "data" comes in a binary format. Binary formats could easily come into play if I think of ML, big data scenarios, and others. If the intent is for OpenWhisk to convert all events into a JSON format then it could probably mean we'd have to convert the binary to hex ending up with something like this:
1. json_data.event = convertToHex(data)
2. json_data.context = ...
I'm not sure this is the most efficient solution from the performance perspective. Users would not be able to benefit from the optimizations brought by various protocols (i.e. protobuf).
> The gateway doesn’t need to decode E and can treat it as an opaque value.
Let's say the Gateway can do this. There are still a few aspects to be taken into consideration:
- The Gateway would have to allocate memory to copy the payload into the new object wrapping the event + the context , provided the event (binary or not) is sent as a "string".
- The Gateway wouldn't be able to stream the event payload, but it would have to buffer it first so that it can read it and then change it. In HTTP the headers are sent first and could be read first; this creates an opportunity for performance improvements b/c not only the request could be validated without reading the body, it could also be stopped earlier if it's malicious. And when it's valid the Gateway could decorate the request with extra headers for the context (which would also be sent ahead of the body) then start streaming the body directly from the client.
> if you want to encode a function that receives three parameters g(E, C, P) where P are
bound params, isn’t this equivalent to a dictionary with three properties
for each argument?
Yes from this perspective it's a fine difference. OpenWhisk internally could choose to use this idea too and keep the E, separated from C and P. This is where it gets arguable whether this is the best way to communicate the intent; I have to admin that probably b/c I'm used with working with a "context" object I'm more biased towards it; subjectively speaking it feels more natural for me and the performance aspects make me even more biased.
> The reason the signature of actions is
dictionary -> dictionary
is for action composition. If your signature is
(dictionary,dictionary) -> dictionary,
you cannot compose actions into a sequence for example.
I think I need some help to understand how a context object could prevent Openwhisk to trigger actions in a sequence.
I'm also adding an extra thought to our thread: if we want to communicate a "user_id" and "app_id" to the actions, but any action can edit the incoming event, how would we make sure that some important fields like these ones can't be overwritten by other actions in a sequence and they can be securely passed through and trusted ?
Thanks,
dragos
________________________________
From: Rodric Rabbah <ro...@gmail.com>
Sent: Saturday, January 7, 2017 8:25:32 AM
To: dev@openwhisk.apache.org
Cc: dev@openwhisk.incubator.apache.org
Subject: Re: Passing a context object to actions
I added a comment to your gist (https://gist.github.com/ddragosd/
3afd5d8678e5dbda48b943a1125aad0c#file-zcloudfront-conf-L71-L93) that
reflects my comments about boxing the event.
Re: Passing a context object to actions
Posted by Rodric Rabbah <ro...@gmail.com>.
I added a comment to your gist (https://gist.github.com/ddragosd/
3afd5d8678e5dbda48b943a1125aad0c#file-zcloudfront-conf-L71-L93) that
reflects my comments about boxing the event.
Re: Passing a context object to actions
Posted by Michael Marth <mm...@adobe.com>.
Hi Matt,
After reviewing the doc [1]:
* I think parameter passing (and typing of those) in-between actions in a sequence looks similar to the original problem, but it is not quite. I have restarted the original thread on that topic. When it comes to parameter passing for application purposes as described in the spec:
I am personally fine with the proposal as is (on the topic of typing parameters). However, if you want to use the descriptor file for tooling as you mention then you probably need an additional flag “required/not-required” for input parameters. In non-tooling scenarios the app developer can implicitly deal with non-required parameters.
* while I was at it, I have collected some notes on the doc. Most comments are nit picks or probably misunderstandings on my side. But wanted to pass them here anyway:
- It is my understanding that sequences are a more general type of action, meaning that pretty much wherever I can call an action I could as well call a sequence as well. If that’s correct, then it might deserve a sentence or two. I was a bit confused by the absence of sequences in the locations below and wondered if the absence meant that the various statements might not apply for sequences:
* line 47: “mapping from a trigger to an action” (can it also be a sequence?)
* line 84: "Every OpenWhisk entity (actions, triggers, feeds)” (also sequences?)
* line 285: this one being the most important example, because it is normative: can a trigger also apply to a sequence? The spec clearly mentions actions only
- line 132: the glossary contains entires that I did not find later on - maybe I missed them. But in particular “project” caught my eye as I expected a construct to organise code (similar to package), but could not find anything later.
- line 252: not sure if the list of runtime names should be in the normative section of a spec, because (as you also write) this list will fluctuate between deployments and over time. OTOH there should be established well known names for well-known runtimes. Maybe point to a community-curated, separate markdown file (where new entries get a PR that can be voted upon)?
- line 268: I was surprised to see execution limits to be part of the app specification (written by an app dev), but guess it might make sense. However, I still wondered how these limits would compare to limits set by the cloud provider. Is it always the lowest value (provided either by cloud provider or app developer) that would apply?
Also in this table: the "valid range”s looked a bit unexpected in a packaging spec (especially the values in that column).
- line 274: the example action definition shows a previously unmentioned “version”. (or I missed it before).
Is this version more than a human-readable string, ie. does it assume SemVer semantics? If the latter, does deploying a “higher” version implicitly undeploy “lower” versions?
Probably, this (versioning) is a more relevant topic and might deserve its own thread...
btw: in line 352 a “version” also shows up in the package definition example - same questions as above :)
- line 333: feedactions have special administrative parameters like CREATE, DELETE, etc. That’s great - I just wondered why that mechanism is only available for feedactions. Would it make sense to make this consistent and have special CREATE, DELETE (“deploy”, “undeploy”) parameters for each 1st class citizen (action, trigger, etc) in OW?
- line 348: wondered what “unlicensed” means. Proprietary?
HTH
Michael
[1] https://github.com/openwhisk/openwhisk-wskdeploy/blob/master/specification/openwhisk_v0.8.pdf
On 16/01/17 18:38, "Michael Marth" <mm...@adobe.com> wrote:
>Thanks Matt - will have a look and report back here if anything comes up.
>
>Cheers
>Michael
>
>
>
>On 11/01/17 22:23, "Matt Rutkowski" <mr...@us.ibm.com> wrote:
>
>>Hi Michael,
>>
>>I should chime in here...
>>
>>Part of the "packaging specification" work we are doing (under the
>>openwhisk-wskdeploy tool/repo) seeks to provide a YAML descriptor of OW
>>packages (incl. Actions, Feeds, Triggers, Event Providers, etc.) including
>>a description of an actions expected inputs and outputs (optionally typed
>>and constrained). This would be used by tooling (and validation)
>>components in order to confirm if Actions that are composed (currently
>>sequenced) are compatible. We have discussed the possibility of also
>>using the information to provide inter-sequence (platform provided)
>>"massaging" of types/names in order for a more automated way to connect
>>Actions without forcing a clone/fork/rewrite.
>>
>>In addition, we provide a manifest file that tells the tool where to
>>"pull" input values from, provide credentials for external services (as
>>well as define their signature and location/protocol). Perhaps you could
>>review this work and provide feedback?
>>
>>Kind regards,
>>Matt
>>
>>
>>
>>From: Michael Marth <mm...@adobe.com>
>>To: "dev@openwhisk.apache.org" <de...@openwhisk.apache.org>
>>Date: 01/11/2017 08:51 AM
>>Subject: Re: Passing a context object to actions
>>
>>
>>
>>Hi Rodric,
>>
>>Re
>>
>>This has come up before. The reason the signature of actions is dictionary
>>-> dictionary is for action composition. If your signature is (dictionary,
>>dictionary) -> dictionary, you cannot compose actions into a sequence for
>>example. One of the tenants of the underlying programming model is that
>>composition, as with any programming language, is a fundamental feature.
>>
>>This is an interesting aspect. Do you happen to have a link to these
>>previous discussions? Would be great to read up on the arguments.
>>
>>Thanks!
>>Michael
>>
>>
>>On 07/01/17 03:13, "Rodric Rabbah" <rodric@gmail.com<
>>mailto:rodric@gmail.com>> wrote:
>>
>> * The fact that we need to unpack the request body and change it has an
>>impact on performance
>>
>>Why? Let the event payload be E, and the request context C, you can pass
>>to
>>your action a new dictionary { “event” -> E, “context” -> C }. The gateway
>>doesn’t need to decode E and can treat it as an opaque value. Can you
>>clarify why the request body must be unpacked?
>>
>> * If we want to send binary payloads in a special format, the API
>>Gateway or some other process in the middle has to know how to
>>decode/encode that payload/Content-Type. So we're limited to what these
>>intermediary processes know.
>>
>>See above, you don’t need to add to the event payload, you can box and
>>decoration in the new object.
>>
>>The same thing happens with default action parameters; they get merged
>>with the event. Basically besides the event itself there's no other way to
>>configure the action with extra params or pass it a context.
>>
>>OpenWhisk actions, as functions, have the signature f: dictionary ->
>>dictionary. You can modify the dictionary any way you like. So if your
>>want
>>to encode a function that receives three parameters g(E, C, P) where P are
>>bound params, isn’t this equivalent to a dictionary with three properties
>>for each argument? The mapping is isomorphic.
>>
>>AWS Lambda allows a similar mechanism to pass a "context" to a function.
>>In OpenWhisk actions the main method signature would allow 2 params
>>instead of 1 (as it is today) and it could look like: function main(event,
>>context)
>>
>>This has come up before. The reason the signature of actions is dictionary
>>-> dictionary is for action composition. If your signature is (dictionary,
>>dictionary) -> dictionary, you cannot compose actions into a sequence for
>>example. One of the tenants of the underlying programming model is that
>>composition, as with any programming language, is a fundamental feature.
>>
>>And really what is a context other than just an added property? Can you
>>show me a case where boxing an opaque value into another dictionary
>>doesn’t
>>give you the feature you want?
>>
>>If you start going down the road of changing the action signature, then I
>>think you have to buy into a much more disruptive idea, where the
>>signature
>>of a method implies legal vs illegal compositions, and perhaps even admit
>>typed parameters.
>>
>>-r
>>
>>
>>
>>
>>
Re: Passing a context object to actions
Posted by Michael Marth <mm...@adobe.com>.
Thanks Matt - will have a look and report back here if anything comes up.
Cheers
Michael
On 11/01/17 22:23, "Matt Rutkowski" <mr...@us.ibm.com> wrote:
>Hi Michael,
>
>I should chime in here...
>
>Part of the "packaging specification" work we are doing (under the
>openwhisk-wskdeploy tool/repo) seeks to provide a YAML descriptor of OW
>packages (incl. Actions, Feeds, Triggers, Event Providers, etc.) including
>a description of an actions expected inputs and outputs (optionally typed
>and constrained). This would be used by tooling (and validation)
>components in order to confirm if Actions that are composed (currently
>sequenced) are compatible. We have discussed the possibility of also
>using the information to provide inter-sequence (platform provided)
>"massaging" of types/names in order for a more automated way to connect
>Actions without forcing a clone/fork/rewrite.
>
>In addition, we provide a manifest file that tells the tool where to
>"pull" input values from, provide credentials for external services (as
>well as define their signature and location/protocol). Perhaps you could
>review this work and provide feedback?
>
>Kind regards,
>Matt
>
>
>
>From: Michael Marth <mm...@adobe.com>
>To: "dev@openwhisk.apache.org" <de...@openwhisk.apache.org>
>Date: 01/11/2017 08:51 AM
>Subject: Re: Passing a context object to actions
>
>
>
>Hi Rodric,
>
>Re
>
>This has come up before. The reason the signature of actions is dictionary
>-> dictionary is for action composition. If your signature is (dictionary,
>dictionary) -> dictionary, you cannot compose actions into a sequence for
>example. One of the tenants of the underlying programming model is that
>composition, as with any programming language, is a fundamental feature.
>
>This is an interesting aspect. Do you happen to have a link to these
>previous discussions? Would be great to read up on the arguments.
>
>Thanks!
>Michael
>
>
>On 07/01/17 03:13, "Rodric Rabbah" <rodric@gmail.com<
>mailto:rodric@gmail.com>> wrote:
>
> * The fact that we need to unpack the request body and change it has an
>impact on performance
>
>Why? Let the event payload be E, and the request context C, you can pass
>to
>your action a new dictionary { “event” -> E, “context” -> C }. The gateway
>doesn’t need to decode E and can treat it as an opaque value. Can you
>clarify why the request body must be unpacked?
>
> * If we want to send binary payloads in a special format, the API
>Gateway or some other process in the middle has to know how to
>decode/encode that payload/Content-Type. So we're limited to what these
>intermediary processes know.
>
>See above, you don’t need to add to the event payload, you can box and
>decoration in the new object.
>
>The same thing happens with default action parameters; they get merged
>with the event. Basically besides the event itself there's no other way to
>configure the action with extra params or pass it a context.
>
>OpenWhisk actions, as functions, have the signature f: dictionary ->
>dictionary. You can modify the dictionary any way you like. So if your
>want
>to encode a function that receives three parameters g(E, C, P) where P are
>bound params, isn’t this equivalent to a dictionary with three properties
>for each argument? The mapping is isomorphic.
>
>AWS Lambda allows a similar mechanism to pass a "context" to a function.
>In OpenWhisk actions the main method signature would allow 2 params
>instead of 1 (as it is today) and it could look like: function main(event,
>context)
>
>This has come up before. The reason the signature of actions is dictionary
>-> dictionary is for action composition. If your signature is (dictionary,
>dictionary) -> dictionary, you cannot compose actions into a sequence for
>example. One of the tenants of the underlying programming model is that
>composition, as with any programming language, is a fundamental feature.
>
>And really what is a context other than just an added property? Can you
>show me a case where boxing an opaque value into another dictionary
>doesn’t
>give you the feature you want?
>
>If you start going down the road of changing the action signature, then I
>think you have to buy into a much more disruptive idea, where the
>signature
>of a method implies legal vs illegal compositions, and perhaps even admit
>typed parameters.
>
>-r
>
>
>
>
>
Re: Passing a context object to actions
Posted by Matt Rutkowski <mr...@us.ibm.com>.
Hi Michael,
I should chime in here...
Part of the "packaging specification" work we are doing (under the
openwhisk-wskdeploy tool/repo) seeks to provide a YAML descriptor of OW
packages (incl. Actions, Feeds, Triggers, Event Providers, etc.) including
a description of an actions expected inputs and outputs (optionally typed
and constrained). This would be used by tooling (and validation)
components in order to confirm if Actions that are composed (currently
sequenced) are compatible. We have discussed the possibility of also
using the information to provide inter-sequence (platform provided)
"massaging" of types/names in order for a more automated way to connect
Actions without forcing a clone/fork/rewrite.
In addition, we provide a manifest file that tells the tool where to
"pull" input values from, provide credentials for external services (as
well as define their signature and location/protocol). Perhaps you could
review this work and provide feedback?
Kind regards,
Matt
From: Michael Marth <mm...@adobe.com>
To: "dev@openwhisk.apache.org" <de...@openwhisk.apache.org>
Date: 01/11/2017 08:51 AM
Subject: Re: Passing a context object to actions
Hi Rodric,
Re
This has come up before. The reason the signature of actions is dictionary
-> dictionary is for action composition. If your signature is (dictionary,
dictionary) -> dictionary, you cannot compose actions into a sequence for
example. One of the tenants of the underlying programming model is that
composition, as with any programming language, is a fundamental feature.
This is an interesting aspect. Do you happen to have a link to these
previous discussions? Would be great to read up on the arguments.
Thanks!
Michael
On 07/01/17 03:13, "Rodric Rabbah" <rodric@gmail.com<
mailto:rodric@gmail.com>> wrote:
* The fact that we need to unpack the request body and change it has an
impact on performance
Why? Let the event payload be E, and the request context C, you can pass
to
your action a new dictionary { “event” -> E, “context” -> C }. The gateway
doesn’t need to decode E and can treat it as an opaque value. Can you
clarify why the request body must be unpacked?
* If we want to send binary payloads in a special format, the API
Gateway or some other process in the middle has to know how to
decode/encode that payload/Content-Type. So we're limited to what these
intermediary processes know.
See above, you don’t need to add to the event payload, you can box and
decoration in the new object.
The same thing happens with default action parameters; they get merged
with the event. Basically besides the event itself there's no other way to
configure the action with extra params or pass it a context.
OpenWhisk actions, as functions, have the signature f: dictionary ->
dictionary. You can modify the dictionary any way you like. So if your
want
to encode a function that receives three parameters g(E, C, P) where P are
bound params, isn’t this equivalent to a dictionary with three properties
for each argument? The mapping is isomorphic.
AWS Lambda allows a similar mechanism to pass a "context" to a function.
In OpenWhisk actions the main method signature would allow 2 params
instead of 1 (as it is today) and it could look like: function main(event,
context)
This has come up before. The reason the signature of actions is dictionary
-> dictionary is for action composition. If your signature is (dictionary,
dictionary) -> dictionary, you cannot compose actions into a sequence for
example. One of the tenants of the underlying programming model is that
composition, as with any programming language, is a fundamental feature.
And really what is a context other than just an added property? Can you
show me a case where boxing an opaque value into another dictionary
doesn’t
give you the feature you want?
If you start going down the road of changing the action signature, then I
think you have to buy into a much more disruptive idea, where the
signature
of a method implies legal vs illegal compositions, and perhaps even admit
typed parameters.
-r
Re: Passing a context object to actions
Posted by Michael Marth <mm...@adobe.com>.
Hi Rodric,
Re
This has come up before. The reason the signature of actions is dictionary
-> dictionary is for action composition. If your signature is (dictionary,
dictionary) -> dictionary, you cannot compose actions into a sequence for
example. One of the tenants of the underlying programming model is that
composition, as with any programming language, is a fundamental feature.
This is an interesting aspect. Do you happen to have a link to these previous discussions? Would be great to read up on the arguments.
Thanks!
Michael
On 07/01/17 03:13, "Rodric Rabbah" <ro...@gmail.com>> wrote:
* The fact that we need to unpack the request body and change it has an
impact on performance
Why? Let the event payload be E, and the request context C, you can pass to
your action a new dictionary { “event” -> E, “context” -> C }. The gateway
doesn’t need to decode E and can treat it as an opaque value. Can you
clarify why the request body must be unpacked?
* If we want to send binary payloads in a special format, the API
Gateway or some other process in the middle has to know how to
decode/encode that payload/Content-Type. So we're limited to what these
intermediary processes know.
See above, you don’t need to add to the event payload, you can box and
decoration in the new object.
The same thing happens with default action parameters; they get merged
with the event. Basically besides the event itself there's no other way to
configure the action with extra params or pass it a context.
OpenWhisk actions, as functions, have the signature f: dictionary ->
dictionary. You can modify the dictionary any way you like. So if your want
to encode a function that receives three parameters g(E, C, P) where P are
bound params, isn’t this equivalent to a dictionary with three properties
for each argument? The mapping is isomorphic.
AWS Lambda allows a similar mechanism to pass a "context" to a function.
In OpenWhisk actions the main method signature would allow 2 params
instead of 1 (as it is today) and it could look like: function main(event,
context)
This has come up before. The reason the signature of actions is dictionary
-> dictionary is for action composition. If your signature is (dictionary,
dictionary) -> dictionary, you cannot compose actions into a sequence for
example. One of the tenants of the underlying programming model is that
composition, as with any programming language, is a fundamental feature.
And really what is a context other than just an added property? Can you
show me a case where boxing an opaque value into another dictionary doesn’t
give you the feature you want?
If you start going down the road of changing the action signature, then I
think you have to buy into a much more disruptive idea, where the signature
of a method implies legal vs illegal compositions, and perhaps even admit
typed parameters.
-r
Re: Passing a context object to actions
Posted by Rodric Rabbah <ro...@gmail.com>.
> * The fact that we need to unpack the request body and change it has an
impact on performance
Why? Let the event payload be E, and the request context C, you can pass to
your action a new dictionary { “event” -> E, “context” -> C }. The gateway
doesn’t need to decode E and can treat it as an opaque value. Can you
clarify why the request body must be unpacked?
> * If we want to send binary payloads in a special format, the API
Gateway or some other process in the middle has to know how to
decode/encode that payload/Content-Type. So we're limited to what these
intermediary processes know.
See above, you don’t need to add to the event payload, you can box and
decoration in the new object.
> The same thing happens with default action parameters; they get merged
with the event. Basically besides the event itself there's no other way to
configure the action with extra params or pass it a context.
OpenWhisk actions, as functions, have the signature f: dictionary ->
dictionary. You can modify the dictionary any way you like. So if your want
to encode a function that receives three parameters g(E, C, P) where P are
bound params, isn’t this equivalent to a dictionary with three properties
for each argument? The mapping is isomorphic.
> AWS Lambda allows a similar mechanism to pass a "context" to a function.
> In OpenWhisk actions the main method signature would allow 2 params
instead of 1 (as it is today) and it could look like: function main(event,
context)
This has come up before. The reason the signature of actions is dictionary
-> dictionary is for action composition. If your signature is (dictionary,
dictionary) -> dictionary, you cannot compose actions into a sequence for
example. One of the tenants of the underlying programming model is that
composition, as with any programming language, is a fundamental feature.
And really what is a context other than just an added property? Can you
show me a case where boxing an opaque value into another dictionary doesn’t
give you the feature you want?
If you start going down the road of changing the action signature, then I
think you have to buy into a much more disruptive idea, where the signature
of a method implies legal vs illegal compositions, and perhaps even admit
typed parameters.
-r