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" <rod...@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 <mma...@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" <rod...@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 <ddas...@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
