Interpolation seems to fail when referencing values from different types of sources.
In the example below, the ingress block contains:
When both interpolations are present, the Terraform plan fails. If either one is removed, the plan succeeds.
This bug was introduced in version 0.9.1.
0.9.1
This example use aws_security_group to demonstrate this issue. However, it's very possible this is a core bug.
variable "cidr_block" {
default = "172.10.0.0/16"
}
resource "aws_eip" "eip" { }
resource "aws_security_group" "allow_all" {
name = "allow_all"
description = "Allow all inbound traffic"
ingress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = [
"192.168.0.0/16",
"${var.cidr_block}",
"${aws_eip.eip.public_ip}/32"
]
}
}
https://gist.github.com/srhaber/0c356008b1b782466a9e6e4368d5e312
Output from terraform plan using 0.9.0:
+ aws_eip.eip
allocation_id: "<computed>"
association_id: "<computed>"
domain: "<computed>"
instance: "<computed>"
network_interface: "<computed>"
private_ip: "<computed>"
public_ip: "<computed>"
vpc: "<computed>"
+ aws_security_group.allow_all
description: "Allow all inbound traffic"
egress.#: "1"
egress.482069346.cidr_blocks.#: "1"
egress.482069346.cidr_blocks.0: "0.0.0.0/0"
egress.482069346.from_port: "0"
egress.482069346.ipv6_cidr_blocks.#: "0"
egress.482069346.prefix_list_ids.#: "0"
egress.482069346.protocol: "-1"
egress.482069346.security_groups.#: "0"
egress.482069346.self: "false"
egress.482069346.to_port: "0"
ingress.#: "1"
ingress.~2281976595.cidr_blocks.#: "<computed>"
ingress.~2281976595.from_port: "0"
ingress.~2281976595.ipv6_cidr_blocks.#: "0"
ingress.~2281976595.protocol: "-1"
ingress.~2281976595.security_groups.#: "0"
ingress.~2281976595.self: "false"
ingress.~2281976595.to_port: "0"
name: "allow_all"
owner_id: "<computed>"
vpc_id: "<computed>"
Plan: 2 to add, 0 to change, 0 to destroy.
Output from terraform plan using 0.9.1:
1 error(s) occurred:
* aws_security_group.allow_all: "ingress.0.cidr_blocks.1" must contain a valid CIDR, got error parsing: invalid CIDR address: ${var.cidr_block}
terraform plan on the example configLooks like #12765 is the culprit here
also hit this in terraform 0.9.1
Also having this problem since upgrading to 0.9.1. I'm using a map of known IP addresses and passing those to security groups. I'm temporarily hardcoding the addresses to resources until this is fixed.
I get the same reported behaviour as well within modules. Variable defaults are set for known places, whereas VPC vars are needed to be parsed into the module.
File Path: /aws_servers/all_the_servers.tf
module "kitteh_litter_box" {
source = "./kitteh_server"
vpc_id = "${module.aws_vpc.vpc_id}"
vpc_cidr_block = "${module.aws_vpc.vpc_cidr_block}"
}
File Path: /aws_servers/kitteh_server/main.tf
variable "vpc_cidr_block" {
description = "The VPC CIDR block"
type = "string"
}
File Path: /aws_servers/kitteh_server/ec2.tf
variable "kitteh_cidr" {
type = "string"
default = "123.123.123.123/32"
}
resource "aws_security_group" "kitteh_server" {
vpc_id = "${var.vpc_id}"
name = "security_kitteh_server"
description = "Allows teh HTTPSing through"
ingress {
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = [
"${var.kitteh_cidr}", // Fails due to being a default var
"${var.vpc_cidr_block}", // Fails due to being passed in
]
}
}
You can comment either out and it will happily move on to planing.
Got hit by the same issue, large scale =(
Hmpf. I just noticed that going back to 0.9.0 isn't an option either, as that version doesn't support passing backend k/v on the command line. For me that pretty much means that 0.9 in general is unusable.
Fixed via: #13046
Thanks for the quick response!
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.
Most helpful comment
also hit this in terraform 0.9.1