Provider implementation of API actions

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.