Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interpolation error when referencing multiple sources #12892

Closed
srhaber opened this issue Mar 20, 2017 · 9 comments
Closed

Interpolation error when referencing multiple sources #12892

srhaber opened this issue Mar 20, 2017 · 9 comments

Comments

@srhaber
Copy link

srhaber commented Mar 20, 2017

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
@jbardin
Copy link
Member

jbardin commented Mar 20, 2017

Looks like #12765 is the culprit here

@hanks
Copy link
Contributor

hanks commented Mar 21, 2017

also hit this in terraform 0.9.1

@zijadmop
Copy link

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.

@matthewhartstonge
Copy link

matthewhartstonge commented Mar 21, 2017

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.

@jangrewe
Copy link

Got hit by the same issue, large scale =(

@jangrewe
Copy link

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.

@grubernaut
Copy link
Contributor

Fixed via: #13046

@jangrewe
Copy link

Thanks for the quick response!

@ghost
Copy link

ghost commented Apr 15, 2020

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.

@ghost ghost locked and limited conversation to collaborators Apr 15, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants