openwhisk-cli

openwhisk-cli copied to clipboard

A trigger is capable of having parameters set on it. When a user does a wsk trigger get <my-trigger> they should receive data back that includes the parameters field.

When the CLI was updated to show the result of the trigger feed invocation it doesn't seem like this parameters field was carried over.

@mdeuser, @csantanapr, @drcariel, @abaruni

Is this a custom/standard trigger or a trigger feed?

For trigger feed the parameters for the functions are stored in trigger_payload down in the feed DB.

So when you do trigger get on a trigger feed (i.e. alarm) you should see the trigger_payload

@eweiter could you provide a series of wsk cli commads on how to reproduce the problem?

Once change that has being discussed is to store the trigger_payload as individual parameters in the trigger itself in the whisk db, and not the feed trigger db.

Bug I would like to get specific reproduce steps to be sure what we are discussing in the context of this issue.

@csantanapr - isn't the trigger_payload unique to the alarms trigger feed actions? i agree that these seem to be a functional duplication of trigger parameters

Related to https://github.com/apache/incubator-openwhisk-wskdeploy/issues/884#issuecomment-386106835.

More context on this issue: This issue is related to #290 It is dealing with Triggers that have associated Feeds. A Trigger with a Feed has two sets of parameters. a) The parameters on the Trigger object itself b) the parameters on the Feed that is attached to the Trigger

The Trigger get command has been updated to now show the result of doing a "GET" against the Trigger feed when calling the wsk trigger get command on a Trigger with a Feed. Due to this we no longer expose certain information that is on the Trigger object itself, such as the parameters that may be stored there.

The commands to recreate this scenario cannot be reproduced as they are blocked by issue #290 . However they would be: wsk trigger create alarm --feed whisk.system/alarms/alarm -p cron "* * * * *" wsk trigger update alarm -p trigger_param "someValue" wsk trigger get alarm and you should be able to find on the "parameters" property a trigger_param: "someValue"

If we expose the "trigger_payload" at the top level of a Trigger that would also address this issue, but fundamentally right now it would be the same. You would be blocked from receiving back that "trigger_payload" param from the wsk trigger get command currently, as it is not returning the Trigger parameters information.

my proposal here would be to no longer mix the concepts of a feed and a trigger and have a separate whisk entity for feeds. then something like wsk feed create <feed_name> /whisk.system/some-feed/feed -p trigger <trigger_name> -p feed_param val could be used. and wsk trigger get, wsk trigger update mytrigger -p foo bar would not collide with wsk feed get, wsk feed update myfeed -p feed_specific_parameter val

feed and triggers are fundamentally two distinct concepts with a feed being composed of a trigger and some event source (except for alarms, of course. another semantics discussion for another day...). i don't think there is a nice way to mix updating/retrieving configuration for either/or in a single command. the simplest way in my mind to remedy this collision would be to split the concepts into distinct entities