Running an empty destroy with an interpolated output fails without setting TF_WARN_OUTPUT_ERRORS:
Terraform v0.11.4
resource "random_id" "foo" {
byte_length = 6
}
output "foo" {
value = "${random_id.foo.b64}"
}
Nothing to happen, it's an empty state file so a destroy should do nothing.
$ terraform destroy -auto-approve
Error: Error applying plan:
1 error(s) occurred:
* output.foo: variable "foo" is nil, but no error was reported
Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.
$ export TF_WARN_OUTPUT_ERRORS=1
$ terraform destroy -auto-approve
Destroy complete! Resources: 0 destroyed.
terraform initterraform destroyTerraform-Kitchen runs a destroy at the start of a test run to make sure that it's running from a clean state (use verify just to rerun the tests alone) so this gets triggered then.
Looked around the issue tracker because I thought this would be covered elsewhere but doesn't appear to be. https://github.com/hashicorp/terraform/issues/17655 and https://github.com/hashicorp/terraform/issues/17425 seem to be different issues and my slightly related, previously raised issue at https://github.com/hashicorp/terraform/issues/17641 is also different to this exact issue.
Hi @tomelliff,
Thanks for filing the issue! This is tangentially related to #17425, and I plan on taking care of them at the same time.
Same issue here.
When we rerun destroy to properly clean up all remaining resources, terraform now fails with output vars not finding their references.
I am having the same issue. v0.11.6
This makes kitchen-terraform difficult as kitchen test will always start with an empty destroy
Is there any fix for this I am facing the same issue in v0.11.7 though I am facing this only for RDS and ELB.
facing the same issue on Terraform v0.11.7
I'm encountering the same issue with terraform 0.11.7. In my case, it appears related to using local variables in a module.
Here's a simple example that reproduces it:
resource "aws_elb" "web-fe" {
listener {
instance_port = 8000
instance_protocol = "http"
lb_port = 80
lb_protocol = "http"
}
}
module "foo" {
source = "./foo"
content = "${aws_elb.web-fe.dns_name}"
}
variable "content" {
default = "default content"
}
locals {
some_content = "${var.content}"
}
resource "local_file" "foo" {
content = "${local.some_content}"
filename = "foobar"
}
$ terraform destroy -force
Error: Error applying plan:
1 error(s) occurred:
* module.foo.var.content: variable "web-fe" is nil, but no error was reported
However in my module if I remove the locals block and use the input variable directly I don't get an error:
variable "content" {
default = "default content"
}
resource "local_file" "foo" {
content = "${var.content}"
filename = "foobar"
}
Hi @russellcardullo! Sorry for that weird error.
Despite the similar symptoms, I expect (due to it being with local values rather than outputs) this is a different bug that'll need it's own fix. It'd be awesome if you could open a new top-level issue for it and complete the issue template (the content in your comment there is a great start!) and then that'll put it on our radar to test as part of preparing the next major release, which already contains some significant changes to how configuration expressions are resolved internally.
Thanks!
I'm fairly certain that this is a similar cause, as outputs and locals are handled in the same way overall.
Issue #18026 is what I was going to reference after 0.12 drops and I can go back and clean up the output/locals edge cases in the destroy graphs.
Thanks @apparentlymart and @jbardin! Let me know if you still need a new top level issue or need me to add information to #18026. Anything else I can provide happy to do so.
Thanks again!
Still having this issue in 0.11.11_linux_amd64 :(
Destroy complete! Resources: 0 destroyed.
I'm going to lock this issue because it has been closed for _30 days_ โณ. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Most helpful comment
Is there any fix for this I am facing the same issue in v0.11.7 though I am facing this only for RDS and ELB.