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

Accessing attributes from resources with count = 0 errors out since version 0.11 #16580

Closed
janschumann opened this issue Nov 7, 2017 · 5 comments

Comments

@janschumann
Copy link
Contributor

Hi,

consider a configuration where specific resources should only be applied for specific environments. This is accomplished by conditionally set the count argument of a resource to 0 or 1 respectively:

resource "aws_s3_bucket" "b" {
  count = "${terraform.workspace == "production" ? 0 : 1}"
  bucket = "my-tf-test-bucket"
  acl    = "private"

  tags {
    Name        = "My bucket"
    Environment = "Dev"
  }
}

Since terraform 0.11, testing on a resource with count = 0 errors out with Resource 'aws_s3_bucket.b' not found for variable 'aws_s3_bucket.b.bucket'

Is this the expected behavior? From my point of view, the resource should exist and a test on the resources count attribute should be possible.

Terraform Version

Terraform v0.11.0-dev

Terraform Configuration Files

resource "aws_s3_bucket" "b" {
  count = 0
  bucket = "my-tf-test-bucket"
  acl    = "private"

  tags {
    Name        = "My bucket"
    Environment = "Dev"
  }
}

output "testbucket" {
  value = "${aws_s3_bucket.b.count > 0 ? aws_s3_bucket.b.bucket : ""}"
}

Expected Behavior

Output testbucket should be empty string w/o error

Actual Behavior

Plan reports the following error:

* output.testbucket: Resource 'aws_s3_bucket.b' not found for variable 'aws_s3_bucket.b.bucket'

Steps to Reproduce

Please list the full steps required to reproduce the issue, for example:

  1. terraform plan
@apparentlymart
Copy link
Contributor

Hi @janschumann! Sorry for this annoying behavior.

I'm surprised to hear that this behavior feels new on 0.11.0 since it's actually a known bug that has existed ever since the conditional expression was implemented, due to some limitations of the interpolation language. (See hashicorp/hil#50 for more details.)

The common workaround today is to exploit the fact that the "splat syntax" can return an empty list when count = 0 and handle this via list operations:

output "testbucket" {
  value = "${element(concat(aws_s3_bucket.b.*.bucket, list("")), 0)}"
}

The additional single-item list here is to ensure that there's always at least one item in this list so that element will work.

The plan is to address this as part of implementing the new version of HCL which incorporates the HIL (interpolation language) functionality while addressing many of the limitations of HIL's type system and evaluator that lead to issues like this. We'll have an opt-in preview version of this soon to gather feedback and find bugs before making Terraform use it by default.

@janschumann
Copy link
Contributor Author

Thanks @apparentlymart. Sorry for bringing this up again! I never came across this, as I in my case everything worked correctly < 0.11! Thanks for the workaround. I will close this issue.

@berney
Copy link

berney commented Apr 1, 2018

If you use list() rather than list("") you will get an empty list rather than a list with an empty string. This is useful for an example like this: -

output "static_ip_addresses" {
  value = "${concat(azurerm_public_ip.static.*.ip_address, list())}"
}

You will get output like this: static_ip_addresses = [].

If you use list("") you will get output like this:

static_ip_addresses = [

]

Or like this: -

static_ip_addresses = [
    8.8.8.8,
    4.4.4.4,

]

@b01
Copy link

b01 commented Jan 22, 2020

This is still an issue in 0.12.18. It would be best if contact just always returns [] regardless of its argument.

@ghost
Copy link

ghost commented Jan 23, 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 Jan 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants