-
Notifications
You must be signed in to change notification settings - Fork 97
Description
This issue is the culmination of discussions and two other issues that were opened, #289 & #290 .
A proposal was talked about for how to handle the above two issues as well as the third issue, the issue of parameters during the creation of a Trigger, and so I wanted to consolidate everything down into a single issue.
This issue tackles three deficiencies currently in the CLI:
- Ability to create a Trigger with Trigger parameters and/or Feed parameters
- Ability to update a Trigger that has a Feed attached, and update that Trigger's Trigger parameters and/or Feed parameters
- Ability to get a Trigger that has a Feed attached, and get that Trigger's Trigger parameters and/or Feed parameters
The functionality of the CLI should operate as follows for all three cases: (showing CLI calls as if they were following the proposal that will be mentioned below):
-
`wsk trigger create myTrigger --feed whisk.system/alarms/alarm -p cron "* * * * *" -p otherParam myParam.
Trigger is created with the "cron" param that is sent to the Feed provider, Trigger has the "otherParam" param stored in its "parameters" property. -
wsk trigger update myTrigger -p cron "* h/2 * * *" -p newParam "0"
Trigger sends "cron" param to Feed provider to update it's params, Trigger updates its "parameters" property and stores "newParam" -
wsk trigger get myTrigger
Result returned will contain the Feed params and the Trigger params.
So you will see Feed having "cron" and Trigger having "otherParam" and "newParam"
The proposal for how to accomplish this is the following:
- The CLI would have to query the Feed Action before creating & updating a Trigger.
- It would like at the Feed Action for what parameters are required and optional.
- It would digest the list of parameters the user is supplying to either the "create" or "update" command and determine if they are a Feed parameter or a Trigger parameter.
- It will send Feed parameters off with the Feed CRUD actions and it will create/update the Trigger object according through the Trigger api calls.
For instance, the alarms/alarm Feed Action has the following configuration:
{
"namespace": "whisk.system",
"name": "alarms",
"version": "0.0.135",
"publish": true,
"annotations": [
{
"key": "description",
"value": "Alarms and periodic utility"
},
{
"key": "parameters",
"value": [
{
"name": "trigger_payload",
"required": false
}
]
}
],
"parameters": [
{
"key": "apihost",
"value": "openwhisk.ng.bluemix.net"
},
{
"key": "trigger_payload",
"value": ""
}
],
"binding": {},
"feeds": [
...
{
"name": "alarm",
"version": "0.0.135",
"annotations": [
{
"key": "feed",
"value": true
},
{
"key": "description",
"value": "Fire trigger when alarm occurs"
},
{
"key": "parameters",
"value": [
{
"name": "cron",
"required": true
},
{
"name": "startDate",
"required": false
},
{
"name": "stopDate",
"required": false
}
]
},
{
"key": "exec",
"value": "nodejs:6"
}
]
}
]
}
So we see through the Annotations and Parameters properties that "trigger_payload" is optional, and we see in the "alarm" Action, "cron" is required, "startDate" is optional, "stopDate" is optional.
All of these would be reserved and so if the CLI detects any of them it sends them to the feed. Else it puts them in the Triggers parameters property