-
Notifications
You must be signed in to change notification settings - Fork 9.5k
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
Un-destroyable partially applied infrastructure #21096
Comments
I suspect the problem here is mainly just that we are running full configuration validation during the We could potentially have a more minimal validation mode that ignores We'd still need to validate any We don't retain local or output values (except the root module, for |
Hi, $ terraform plan -destroy var.aws_region var.aws_secret_access_key Refreshing Terraform state in-memory prior to plan... data.aws_availability_zones.available: Refreshing state... Error: Invalid index on vpc.tf line 51, in resource "aws_route_table_association" "pkb": The given key does not identify an element in this collection value. Error: Invalid index on vpc.tf line 51, in resource "aws_route_table_association" "pkb": The given key does not identify an element in this collection value. |
A recent duplicate led me to a clearer reproduction. The failure here is during the refresh walk, which is partially driven by the configuration. Because data sources need to be fully re-evaluated during refresh, the entire config is loaded. Problems arise when the managed resource instances in the config do not match what is in the state. This leads to the situation where expressions from numerous places could require evaluating non-existent resource instances. The workaround for refresh-time failures is |
I can confirm this is still happening as of terraform 1.0.3. Is there any chance we can see some action here? |
Hi @jnixon-blue, The issue here is a case where an invalid root module output configuration cannot be applied, and since Unfortunately, due to the obscure nature of the issue, and availability of a direct workaround, we have not gotten to the work necessary to fix the destroy evaluation process for root outputs in this case. If you happen to have a similar error that is not caused by an invalid configuration, I suggest you file a new issue with the information requested in the issue template. Thanks! |
Applying the config below results in the following (expected) errors:
which brings me to a state where I cannot destroy this "partially" applied infrastructure.
I'm forced to touch the config and remove pieces of it which were never actually applied, but are interpolated anyway and preventing Terraform from destroying other parts.
I assume the problem is more complex than I can imagine, but can't we just interpolate blocks of config for which we have existing state during refresh and destroy - or is there a reason we need to interpolate whole config?
Terraform Version
e8ee3f1
It's worth noting this is not a regression and this bug exists in 0.11 and most likely all previous versions too.
Terraform Configuration Files
Steps to Reproduce
terraform init
terraform apply
terraform destroy
This might theoretically also be solved by #18994 but only partially as we'd still need to parse config for refresh anyway.
The text was updated successfully, but these errors were encountered: