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

Running an empty destroy with an interpolated output fails #17691

Closed
tomelliff opened this issue Mar 26, 2018 · 11 comments · Fixed by #17768
Closed

Running an empty destroy with an interpolated output fails #17691

tomelliff opened this issue Mar 26, 2018 · 11 comments · Fixed by #17768
Assignees

Comments

@tomelliff
Copy link
Contributor

Running an empty destroy with an interpolated output fails without setting TF_WARN_OUTPUT_ERRORS:

Terraform Version

Terraform v0.11.4

Terraform Configuration Files

resource "random_id" "foo" {
  byte_length = 6
}

output "foo" {
  value = "${random_id.foo.b64}"
}

Expected Behavior

Nothing to happen, it's an empty state file so a destroy should do nothing.

Actual Behavior

$ 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.

Steps to Reproduce

  1. terraform init
  2. terraform destroy

Additional Context

Terraform-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.

References

Looked around the issue tracker because I thought this would be covered elsewhere but doesn't appear to be. #17655 and #17425 seem to be different issues and my slightly related, previously raised issue at #17641 is also different to this exact issue.

@jbardin jbardin self-assigned this Mar 26, 2018
@jbardin
Copy link
Member

jbardin commented Mar 26, 2018

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.

@djsly
Copy link

djsly commented Mar 28, 2018

Same issue here.

When we rerun destroy to properly clean up all remaining resources, terraform now fails with output vars not finding their references.

@smastrorocco
Copy link

I am having the same issue. v0.11.6

This makes kitchen-terraform difficult as kitchen test will always start with an empty destroy

@abhishekamralkar
Copy link

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.

@alwaysastudent
Copy link

facing the same issue on Terraform v0.11.7

@russellcardullo
Copy link

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:

main.tf

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}"
}

module foo/main.tf

variable "content" {
  default = "default content"
}

locals {
  some_content = "${var.content}"
}

resource "local_file" "foo" {
    content     = "${local.some_content}"
    filename = "foobar"
}

Running terraform destroy on empty state:

$ 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:

Working foo/main.tf

variable "content" {
  default = "default content"
}

resource "local_file" "foo" {
    content     = "${var.content}"
    filename = "foobar"
}

@apparentlymart
Copy link
Contributor

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!

@jbardin
Copy link
Member

jbardin commented Jun 23, 2018

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.

@russellcardullo
Copy link

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!

@lukemao
Copy link

lukemao commented Jan 4, 2019

Still having this issue in 0.11.11_linux_amd64 :(

Destroy complete! Resources: 0 destroyed.

@ghost
Copy link

ghost commented Mar 30, 2020

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.

@ghost ghost locked and limited conversation to collaborators Mar 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants