Closed dalehamel closed 9 years ago
Thanks for the detailed report, @dalehamel.
I think the problem with name_servers here is actually even larger scoped. This simple test fails to output anything:
resource "aws_route53_zone" "prod" {
name = "prod.mydomain.com"
}
output "ns" { value = "${join(",", aws_route53_zone.prod.name_servers)}" }
There's some general issue with referencing TypeList
attributes that we'll need to get to the bottom of.
@phinze There's a PR which is solving exactly this: https://github.com/hashicorp/terraform/pull/2157 :wink:
Oh right! :heart: @radeksimko going to review that now
Feel free to reopen if you still experience the issue in the upcoming version (or in build from master
).
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.
I have the following code which attempts to build a zone with subzones, and set the nameserver records of the subzones to those defined in a delegation set.
This is basically a count-based version of the sample code for route53, (https://terraform.io/docs/providers/aws/r/route53_zone.html). This code fails, giving messages like:
Interestingly, the output varies from run to run on which index it gets mad at, indicating possibly non-deterministic behavior (rerun plan and you'll see what I mean).
If i specify that it should use, for instance
That works totally fine, where as this does not:
So it appears terraform is getting mad about the fact that name_servers is a list, or maybe that name_servers.0 does not yet exist.
Even more curiously, if I simply build the records block with invalid records (for instance, specifying to use sub.*.id), then go back and change the code later, it works happily. I assume this is because the delegation set resources exist, and it can actually find the value now.
So, I can successfully build it with:
Which outputs this plan:
Then if I change back to the original code (referencing name_servers.INDEX) it applies works totally fine, setting the name servers to the correct value.
My theory is that terraform doesn't like the list attributes when doing a splat, where the lists don't exist yet.
@mitchellh @phinze for :eyes: