Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[proposal] Warn google_bigtable_instance without prevent_destroy #23

Open
wata727 opened this issue Sep 26, 2020 · 3 comments
Open

[proposal] Warn google_bigtable_instance without prevent_destroy #23

wata727 opened this issue Sep 26, 2020 · 3 comments
Labels
enhancement New feature or request

Comments

@wata727
Copy link
Member

wata727 commented Sep 26, 2020

See https://www.terraform.io/docs/providers/google/r/bigtable_instance.html

Note: It is strongly recommended to set lifecycle { prevent_destroy = true } on instances in order to prevent accidental data loss. See Terraform docs for more information on lifecycle parameters.

@wata727 wata727 added the enhancement New feature or request label Sep 26, 2020
@PatMyron
Copy link
Contributor

PatMyron commented Feb 2, 2022

Love the idea of encouraging explicit prevent_destroy values for stateful resource types: #25, #30, #37, hashicorp/terraform#24658, aws-cloudformation/cfn-lint#1232

Few thoughts:

  1. One rule could cover the indefinitely expanding list of resource types, here's a similar expanding list for a similar rule:
    https://github.com/aws-cloudformation/cfn-lint/blob/main/src/cfnlint/data/AdditionalSpecs/StatefulResources.json
  2. Useful for other providers like aws and azurerm as well
  3. Don't think we should enforce a certain value of prevent_destroy itself, think we should just encourage explicitness alone

@PatMyron
Copy link
Contributor

PatMyron commented Feb 2, 2022

@wata727
Copy link
Member Author

wata727 commented Feb 3, 2022

The reason I haven't worked on this is because I was worried that declaring a prevent_destroy for a test instance, could seem redundant. I want to avoid warnings for code that works correctly as much as possible.

However, I agree that it is good practice to always declare prevent_destroy so that it can be explicitly declared whether it is for testing that may be deleted or data that should not be deleted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

No branches or pull requests

2 participants