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
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.