Terraform: Interpolation error when referencing multiple sources

Created on 20 Mar 2017  ยท  9Comments  ยท  Source: hashicorp/terraform

Interpolation seems to fail when referencing values from different types of sources.

In the example below, the ingress block contains:

  • Hard-coded value
  • Interpolated variable
  • Interpolated resource attribute

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.

Terraform Version

0.9.1

Affected Resource(s)

  • aws_security_group

This example use aws_security_group to demonstrate this issue. However, it's very possible this is a core bug.

Terraform Configuration Files

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"
    ]
  }
}

Debug Output

https://gist.github.com/srhaber/0c356008b1b782466a9e6e4368d5e312

Expected Behavior

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.

Actual Behavior

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}

Steps to Reproduce

  1. Upgrade to Terraform 0.9.1
  2. Run terraform plan on the example config
bug core

Most helpful comment

also hit this in terraform 0.9.1

All 9 comments

Looks 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.

Example

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.

Was this page helpful?
0 / 5 - 0 ratings