Hello. I am developing the citrixadc provider. ( https://github.com/citrix/terraform-provider-citrixadc )
In this provider we use the HTTP REST API ( NITRO) implemented on citrixadc to implement the terraform resources.
We have a request to implement some functionality in the API that does not match the typical resource life cycle.
For example we need to implement the reboot
action or sync configuration files
action.
There is no state on the target node for these actions so a create, update, delete life cycle is irrelevant.
So far these cases are handled with null_provider
and local-exec
provisioner to issue the API calls.
What would be the best practice to incorporate this functionality in the provider itself?
1 Like
There is an āinvitation accepterā in the GitHub provider which does a similar thing; it invokes an action, but doesnāt actually manage a resource. Iāve not used it, but you may be able to learn from its implementation.
Further to what @kpfleming said, in cases where a provider wants to model a special action that isnāt naturally a Create/Update/Delete a common approach is to create a resource type whose name implies a verb, like citrixadc_rebooter
, and design it such that it only takes action on Create
.
Then you need to define some way for the user to explicitly indicate that the action needs to be taken in terms of a change elsewhere in the configuration. In some cases thatās done by just marking all arguments as ForceNew
, and then the behavior is to āre-createā this pseudo-object any time its configuration changes. If a more explicit approach is required for a particular action then you could follow the pattern of keepers
on the resource types in the random
provider, where thereās an explicit arbitrary bag of data which has ForceNew
set on it, so the user can assign anything into there that should trigger a re-run of the action on change.
With all of that said, it might well be the case that these particular actions are not a good fit for Terraform and would be better handled elsewhere. Terraformās lifecycle is intended declarative modelling, whereas both of the actions you described here sound like administrative actions that are 100% side-effect and that would not be implied by any change to the configuration. It could make the most sense to omit these from the Terraform provider altogether, and encourage users to use the official CLI or some other tooling to automate these ad-hoc actions, using Terraform only to create and update configuration for the long-lived infrastructure objects.
Thanks for the suggestions.
I understand this is not the intended use of Terraform but we need to embed these actions in the execution of a plan.
For example some resources are created/updated then some action needs to happen and after that the rest of the resources can be created/updated.
Using the null_provider
with local-exec
seems ugly and requires the user to have more intimate knowledge of the API.
Again thanks for the suggestions.