aws_network_interface.private_ips empty string in 0.8.2 #10908

eric-johnson · 2016-12-22T20:17:56Z

Hi there,

I upgraded to 0.8.2 and am having issues getting ip addresses off of aws_network_interfaces.

Terraform Version

0.8.2 (does not happen in 0.8.1)

Affected Resource(s)

aws_network_interface

Terraform Configuration Files

The full config is here: https://gist.github.com/eric-johnson/e73255b833844fbb1e010daf1b5c107b

...

resource "aws_network_interface" "test" {
  subnet_id = "${element(split(",", module.vpc.external_subnets), 0)}"
  subnet_id = "${aws_subnet.external.id}"
  security_groups = ["${aws_security_group.sg.id}"]
  tags { Name = "test-8.2" }
}

resource "null_resource" "test" {
  triggers {
    id = "${aws_network_interface.test.subnet_id}"
  }

  provisioner "local-exec" {
    command = "echo ${join("-", aws_network_interface.test.private_ips)} ${jsonencode(aws_network_interface.test.private_ips)}"
  }
}

Output

https://gist.github.com/eric-johnson/e73255b833844fbb1e010daf1b5c107b
I have a debug log, but I'd rather not have to strip out sensitive info from it.

Expected Behavior

The local-exec provisioner should be printing out the private_ips of the network_interface.
This line should have the private ip address in it.

Actual Behavior

The network interface's private_ips was a list with an empty string.

Steps to Reproduce

terraform apply

Important Factoids

This does not occur in terraform 0.8.1

The text was updated successfully, but these errors were encountered:

2rs2ts · 2016-12-23T19:28:12Z

This broke a workaround I was using to get around another issue about list flattening. 😞

Through bisecting, I was able to determine that this was caused by #10787 cc @jbardin. I'll try to see if I can fix it, but I'm not really familiar with the codebase and barely know Go, so I wouldn't get my hopes up if I were you.

@jszwedko

The change in hashicorp#10787 used flatmap.Expand to fix interpolation of nested maps, but it broke interpolation of Sets such that their elements were not represented. For example, the expected string representation of a splatted aws_network_interface.whatever.*.private_ips should be: ``` [{Variable (TypeList): [{Variable (TypeString): 10.41.17.25}]} {Variable (TypeList): [{Variable (TypeString): 10.41.22.236}]}] ``` But instead it became: ``` [{Variable (TypeList): [{Variable (TypeString): }]} {Variable (TypeList): [{Variable (TypeString): }]}] ``` This is because the expandArray function of expand.go treated arrays to exclusively be lists, e.g. not sets. The old code used to match for numeric keys, so it would work for sets, whereas expandArray just assumed keys started at 0 and ascended incrementally. Remember that sets' keys are numeric, but since they are hashes, they can be any integer. The result of assuming that the keys start at 0 led to the recursive call to flatmap.Expand not matching any keys of the set, and returning nil, which is why the above example has nothing where the IP addresses used to be. So we bring back that matching behavior, but we move it to expandArray instead. We've modified it to not reconstruct the data structures like it used to when it was in the Interpolator, and to use the standard int sorter rather than implementing a custom sorter since a custom one is no longer necessary thanks to the use of flatmap.Expand. Fixes hashicorp#10908, and restores the viability of the workaround I posted in hashicorp#8696. Big thanks to @jszwedko for helping me with this fix. I was able to diagnose the problem along, but couldn't fix it without his help. Signed-off-by: Jesse Szwedko <jesse.szwedko@getbraintree.com>

@jszwedko

The change in hashicorp#10787 used flatmap.Expand to fix interpolation of nested maps, but it broke interpolation of Sets such that their elements were not represented. For example, the expected string representation of a splatted aws_network_interface.whatever.*.private_ips should be: ``` [{Variable (TypeList): [{Variable (TypeString): 10.41.17.25}]} {Variable (TypeList): [{Variable (TypeString): 10.41.22.236}]}] ``` But instead it became: ``` [{Variable (TypeList): [{Variable (TypeString): }]} {Variable (TypeList): [{Variable (TypeString): }]}] ``` This is because the expandArray function of expand.go treated arrays to exclusively be lists, e.g. not sets. The old code used to match for numeric keys, so it would work for sets, whereas expandArray just assumed keys started at 0 and ascended incrementally. Remember that sets' keys are numeric, but since they are hashes, they can be any integer. The result of assuming that the keys start at 0 led to the recursive call to flatmap.Expand not matching any keys of the set, and returning nil, which is why the above example has nothing where the IP addresses used to be. So we bring back that matching behavior, but we move it to expandArray instead. We've modified it to not reconstruct the data structures like it used to when it was in the Interpolator, and to use the standard int sorter rather than implementing a custom sorter since a custom one is no longer necessary thanks to the use of flatmap.Expand. Fixes hashicorp#10908, and restores the viability of the workaround I posted in hashicorp#8696. Big thanks to @jszwedko for helping me with this fix. I was able to diagnose the problem along, but couldn't fix it without his help.

@jszwedko

The change in hashicorp#10787 used flatmap.Expand to fix interpolation of nested maps, but it broke interpolation of sets such that their elements were not represented. For example, the expected string representation of a splatted aws_network_interface.whatever.*.private_ips should be: ``` [{Variable (TypeList): [{Variable (TypeString): 10.41.17.25}]} {Variable (TypeList): [{Variable (TypeString): 10.41.22.236}]}] ``` But instead it became: ``` [{Variable (TypeList): [{Variable (TypeString): }]} {Variable (TypeList): [{Variable (TypeString): }]}] ``` This is because the expandArray function of expand.go treated arrays to exclusively be lists, e.g. not sets. The old code used to match for numeric keys, so it would work for sets, whereas expandArray just assumed keys started at 0 and ascended incrementally. Remember that sets' keys are numeric, but since they are hashes, they can be any integer. The result of assuming that the keys start at 0 led to the recursive call to flatmap.Expand not matching any keys of the set, and returning nil, which is why the above example has nothing where the IP addresses used to be. So we bring back that matching behavior, but we move it to expandArray instead. We've modified it to not reconstruct the data structures like it used to when it was in the Interpolator, and to use the standard int sorter rather than implementing a custom sorter since a custom one is no longer necessary thanks to the use of flatmap.Expand. Fixes hashicorp#10908, and restores the viability of the workaround I posted in hashicorp#8696. Big thanks to @jszwedko for helping me with this fix. I was able to diagnose the problem along, but couldn't fix it without his help.

2rs2ts · 2016-12-23T23:41:11Z

Thanks to some help from a colleague, I was able to submit a fix. 🤞

stack72 · 2017-01-04T10:28:19Z

Related to #10926

mcraig88 · 2017-02-21T18:05:06Z

This reproduces in v0.8.7.

resource 'null_resource.test' config: use of the splat ('*') operator must be wrapped in a list declaration
module vpc.us-west-2.root: 1 error(s) occurred:
resource 'null_resource.test' config: use of the splat ('*') operator must be wrapped in a list declaration

aaomoware · 2017-02-22T12:23:50Z

Terraform v0.8.6

same ish.
"dns_ip_addresses.#": "0",

ghost · 2020-04-16T02:17:07Z

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.

apparentlymart added bug provider/aws labels Dec 22, 2016

roderickrandolph mentioned this issue Dec 22, 2016

AWS Route53 record fails to apply when instance is stopped / shutdown #6770

Closed

2rs2ts mentioned this issue Dec 23, 2016

Flattening a list in 0.7.3 #8696

Closed

2rs2ts mentioned this issue Dec 23, 2016

Fix string representation of sets during interpolation #10920

Closed

stack72 added core and removed provider/aws labels Jan 4, 2017

jbardin mentioned this issue Jan 4, 2017

fix flatmap.Expand to work with the schema.Set representation #11042

Merged

mitchellh mentioned this issue Jan 8, 2017

aws_directory_service_directory returns list of empty elements for dns_ip_addresses #10926

Closed

jbardin closed this as completed in #11042 Jan 9, 2017

ghost locked and limited conversation to collaborators Apr 16, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

aws_network_interface.private_ips empty string in 0.8.2 #10908

aws_network_interface.private_ips empty string in 0.8.2 #10908

eric-johnson commented Dec 22, 2016

2rs2ts commented Dec 23, 2016

2rs2ts commented Dec 23, 2016

stack72 commented Jan 4, 2017

mcraig88 commented Feb 21, 2017

aaomoware commented Feb 22, 2017

ghost commented Apr 16, 2020

aws_network_interface.private_ips empty string in 0.8.2 #10908

aws_network_interface.private_ips empty string in 0.8.2 #10908

Comments

eric-johnson commented Dec 22, 2016

Terraform Version

Affected Resource(s)

Terraform Configuration Files

Output

Expected Behavior

Actual Behavior

Steps to Reproduce

Important Factoids

2rs2ts commented Dec 23, 2016

2rs2ts commented Dec 23, 2016

stack72 commented Jan 4, 2017

mcraig88 commented Feb 21, 2017

aaomoware commented Feb 22, 2017

ghost commented Apr 16, 2020