Provisioner support for validation commands (during plan) and update commands (during apply)

[AdrianC-BBL]

Terraform Version

v1.14

Use Cases

When dealing with difficult APIs for which a working provider does not exist it is sometimes pragmatically necessary to resort to using provisioners to invoke scripts to call those difficult APIs for external system configuration setup and (eventual) removal. Obviously this is suboptimal, but unless you are able to code in go and build a new provider or fix existing provider shortcomings for yourself, the only other option is to not use Terraform at all.

To be crystal clear up front, I acknowledge and understand that this is not the intended use of local-exec provisioners.

The feature I am requesting is a way to perform external non-terraform resource configuration validation (during plan) and update (during apply) via provisioners (typically on terraform_data resources).

Attempted Solutions

N/A

Proposal

I am in this unfortunate situation and currently have to use a terraform_data resource with a when=create local-exec provisioner to configure the target system and a when=destroy local-exec provisioner to later remove that configuration. At a simplistic level this works, but (obviously) it has the downside of not allowing terraform to check/validate and update the configuration of the target system if necessary, each time it runs.

The feature I am requesting is a way to perform external validation (during plan) and update (during apply). It might be done via two when values using the proposed example syntax below. If a validate provisioner failed during plan, the resource would be flagged to indicate that any update provisioners need to be called during apply.

provisioner "local-exec" {
    when = validate
    command = "...."    # Check the external system and fail if it's not configured correctly
}

provisioner "local-exec" {
    when = update
    command = "...."     # Fix up the external system's incorrect configuration

There are some obvious variations to this approach that would likely be equally effective, like simply having a failing validate provisioner mark the resource as tainted so the create provisioners would then be called during apply. This would mean the create provisioner would then be responsible for detecting any existing partially-completed configuration and fixing it, rather than starting from scratch (although well-written local-exec scripts would be doing this already).

Here's another possible syntax that would allow for more controlled validation/update of external configuration via provisioners:

provisioner "local-exec" {
    validate_command = "...."
    update_command = "...."
}

The intention here should be clear enough: call the validate_command during plan, and the update_command during apply if the validate_command fails.

I realise this is likely to be an unpopular request with the development team, since I'm asking them to add functionality purely to deal with other peoples' failure to build terraform provider components correctly. I'm only asking because I am the poor bunny who is currently stuck between a rock and hard place :-(

References

None found

[jbardin]

Hi @AdrianC-BBL,

Validation as it is defined by Terraform is an entirely offline process, ensuring only that the statically known configuration is valid and conforms to the schemas of each resource. Checking a remote system during validation is not allowed during that process. That type of checking must be done during the planning process, not during validation.

There is already work underway for Terraform Actions, which should eventually be able to supplant provisioners. Actions have a PlanAction RPC, and will have more fine grained events to trigger them. They are not quite ready for the use case you are describing here, but it is probably going to be the most likely route to having more control than the current provisioners offer.

Thanks!

[crw]

Adding the boilerplate so future viewers know how to show support for this issue:

Thanks for this feature request! If you are viewing this issue and would like to indicate your interest, please use the 👍 reaction on the issue description to upvote this issue. We also welcome additional use case descriptions. Thanks again!