This change allows "triggers" to be associated with functions ("actions") at the time of deployment. These are not OpenWhisk triggers but rather a (currently experimental) form of trigger managed elsewhere. Unlike OpenWhisk triggers, these do not require OpenWhisk rules to link them to functions. Rather, each trigger is bound to exactly one function (a function may have more than one trigger, however).
CRUD operations on these triggers are currently managed via system actions. The linkage between functions and triggers is a loose one, recorded in annotations on the function. The deployer will delete associated triggers when it deletes a function. But, note that deletion of functions is often not done by the deployer but using the more primitive function delete operation driven directly from nim or doctl sls undeploy. If this direction is adopted, those CLIs will need to change so as to go through the deployer when deleting a function.
This change allows "triggers" to be associated with functions ("actions") at the time of deployment. These are not OpenWhisk triggers but rather a (currently experimental) form of trigger managed elsewhere. Unlike OpenWhisk triggers, these do not require OpenWhisk rules to link them to functions. Rather, each trigger is bound to exactly one function (a function may have more than one trigger, however).
CRUD operations on these triggers are currently managed via system actions. The linkage between functions and triggers is a loose one, recorded in annotations on the function. The deployer will delete associated triggers when it deletes a function. But, note that deletion of functions is often not done by the deployer but using the more primitive function delete operation driven directly from
nimordoctl sls undeploy. If this direction is adopted, those CLIs will need to change so as to go through the deployer when deleting a function.