Hello!
My team is currently writing a custom Terraform Provider. The API on which this Provider is based exposes the option to create various resources in a given system. Besides the resources we can also trigger some actions in this system. These actions are related to the resources but do not manipulate them. For example we have a “trigger workflow execution” which requires as an input some of the already created resources and also some additional configuration (if the user would like to fine-tune the default one). I would like to understand what would be the best way to define such actions in Terraform?
For example should we define a “wokflow_execution” resource or any other definition/structure would work better? I would appreciate an example.
Terraform does not currently have first-class support for this sort of arbitrary action, since its workflow is designed around the common verbs Create, Read, Update, Delete.
However, similar to how we can model arbitrary actions in a REST API using POST, we can potentially model arbitrary actions in Terraform using Create as long as there’s a means within the resource configuration to allow the user to indicate when the action might need to be taken again in future, after the object is already created.
The null_resource resource type is a simple example of this technique: it doesn’t actually do anything by default, but it can be used to house provisioners whose execution is not tied to the creation of any specific object. It has a triggers map which is implemented such that any change to its value (compared to what is saved in the Terraform state) will cause the object to be recreated.
Your “workflow execution” resource type could follow a similar model: call the remote API to trigger the workflow in the resource type’s Create function, and then have an arbitrary map attribute that is marked in the schema as ForceNew: true so users of that resource type can indicate which changes should prompt a re-execution of the workflow.
For a resource type like this, usually all of the arguments in the schema will be marked as ForceNew: true and the resource type won’t have an Update implementation at all: any change to the settings would then prompt re-running the workflow.
That’s not mandatory, though… if in your case it would be useful to be able to change the workflow execution settings for a future execution without actually executing the workflow then you could choose instead to have a completely empty Update implementation and thus effectively ignore any changes except on the arguments specifically configured as ForceNew: true.