Terraform: core: List interpolated into output exposes raw internal list serialization

Created on 4 Apr 2016  ยท  8Comments  ยท  Source: hashicorp/terraform

Based on the docs I expected name_servers output variable to be a list. It looks like a string of names and ID's merged.

To reproduce:
sample.tf

resource "aws_route53_zone" "primary" {
    name = "example.dev"
}
output "ns" {
    value = "${aws_route53_zone.primary.name_servers}"
}

Produces:

ns = B780FFEC-B661-4EB8-9236-A01737AD98B6ns-1227.awsdns-25.orgB780FFEC-B661-4EB8-9236-A01737AD98B6ns-1950.awsdns-51.co.ukB780FFEC-B661-4EB8-9236-A01737AD98B6ns-342.awsdns-42.comB780FFEC-B661-4EB8-9236-A01737AD98B6ns-966.awsdns-56.netB780FFEC-B661-4EB8-9236-A01737AD98B6

Expected:

ns = [
"ns-1227.awsdns-25.org",
"ns-1950.awsdns-51.co.uk",
"ns-342.awsdns-42.com",
"ns-966.awsdns-56.net"
]
bug core

Most helpful comment

Hi @den-t. Sorry for this confusing result.

What's going on here is that Terraform is erroneously showing you an implementation detail of how it represents lists internally. Since the underlying variable table is a mapping from string to string, lists are represented as flat strings with a special GUID separator. This isn't supposed to be something users should ever know about, so it's a bug that Terraform is showing that to you.

At present Terraform doesn't support non-string outputs, so the closest thing you can do is to produce a delimited string of your own:

output "ns" {
    value = "${join(" ", aws_route53_zone.primary.name_servers)}"
}

Anything that is consuming that output would then need to split it again to recover the original list. For example, here is how a parent module might split it:

    ${split(" ", module.foo.ns)}

It's intentional that the configuration you tried to use didn't work, but it's a bug that Terraform didn't give you a useful error message explaining what went wrong. I'm going to re-title this issue to describe _that_ bug; I hope the join/split workaround works for you and lets you make progress.

All 8 comments

Hi @den-t. Sorry for this confusing result.

What's going on here is that Terraform is erroneously showing you an implementation detail of how it represents lists internally. Since the underlying variable table is a mapping from string to string, lists are represented as flat strings with a special GUID separator. This isn't supposed to be something users should ever know about, so it's a bug that Terraform is showing that to you.

At present Terraform doesn't support non-string outputs, so the closest thing you can do is to produce a delimited string of your own:

output "ns" {
    value = "${join(" ", aws_route53_zone.primary.name_servers)}"
}

Anything that is consuming that output would then need to split it again to recover the original list. For example, here is how a parent module might split it:

    ${split(" ", module.foo.ns)}

It's intentional that the configuration you tried to use didn't work, but it's a bug that Terraform didn't give you a useful error message explaining what went wrong. I'm going to re-title this issue to describe _that_ bug; I hope the join/split workaround works for you and lets you make progress.

Hi @den-t! This will be fixed in 0.7 when native list support lands. As @apparentlymart mentions though, the split/join workaround is the currently recommended way to achieve this.

Thank you guys!
I'm currently using this value inside the same module, so element() interpolation works for me.
I've tested joining the list for output and it looks as expected, so the proposed workaround is actionable if need be.

Seems like #6011 will fix this issue by rendering it obsolete. :tada:

@jen20 this should be resolved in master now, right?

same problem when using formatlist:

output "ip" {
    value = "${join(", ", google_compute_instance.gce.*.name)}"
}

the output is:

ip     = venus, mercury

but:

output "ip" {
    value = "${formatlist("%v:%v,", google_compute_instance.gce.*.name, google_compute_instance.gce.*.network_interface.0.access_config.0.assigned_nat_ip)}"
}

the output is:

ip     = B780FFEC-B661-4EB8-9236-A01737AD98B6venus:104.197.xx.xx,B780FFEC-B661-4EB8-9236-A01737AD98B6mercury:146.148.xx.xxx,B780FFEC-B661-4EB8-9236-A01737AD98B6

This is fixed in master, even the last comment's example.

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.

Was this page helpful?
0 / 5 - 0 ratings