Open luizcavalcanti opened 2 months ago
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!
Oh this is quite timely; we have a user who inadvertently destroyed a TF-created K8s cluster by naively setting --auto-approve
in a CI job while using the MGC provider.
It does seem reasonable to have an additional yes-I-am-sure-go-eat-my-data commandline option to complement --auto-approve, in particular given situations like the above (where AIUI the user's template had not changed, but something in the backend provider did). Users who didn't set the option would have the apply just return non-zero and the job would then fail, allowing them to go figure it out.
For reference, the docs at https://developer.hashicorp.com/terraform/cli/commands/apply state:
Warning: If you use -auto-approve, we recommend making sure that no one can change your infrastructure outside of your Terraform workflow. This minimizes the risk of unpredictable changes and configuration drift.
However, in the case you're running on public cloud infrastructure, you are implicitly dependent on them, so you can't actually "make sure".
Terraform Version
Use Cases
There have been cases in my organization where a customer, when creating a terraform pipeline, used a plan/apply --auto-approve sequence that caused stateful resources to be recreated.
This happened because the provider did not support updating the changed properties, which ends up recreating a cluster and destroying user data.
Attempted Solutions
None
Proposal
I believe we can have a more explicit flag than
--auto-approve
for when the apply includes deleting and recreating a resource, something like--allow-recreate-resources-without-update-support
or something like that.References
No response