aws_elb does not have attribute "name" when optional parameter not provided

[lwcbiking]

Terraform Version

Terraform v0.11.0

• provider.aws v1.5.0

Affected Resource(s)

• aws_elb
• aws_cloudwatch_metric_alarm

Terraform Configuration Files

variable "aws_region" {
  type        = "string"
  default     = "us-east-1"
  description = "AWS region to create resources in"
}

terraform {
  required_version = ">= 0.11.0"
}

provider "aws" {
  version = "~> 1.5"
  region = "${var.aws_region}"
}

resource "aws_elb" "elb" {
  subnets         = [
    "subnet-99999ghd"
  ]
  internal        = "true"
  security_groups = [
    "sg-99ew9d99"
  ]

  listener {
    instance_port      = "80"
    instance_protocol  = "HTTP"
    lb_port            = 80
    lb_protocol        = "http"
  }

  health_check {
    healthy_threshold   = 2
    unhealthy_threshold = 2
    timeout             = 5
    target              = "HTTP:80/healthcheck"
    interval            = 15
  }

  tags {
    Terraform   = "true"
    Name        = "app-test"
  }
}

resource "aws_cloudwatch_metric_alarm" "elb_unhealthy_instance_count" {
  depends_on = [
    "aws_elb.elb"
  ]
  alarm_name = "app-test-ElbUnhealthInstanceCount"
  comparison_operator = "GreaterThanOrEqualToThreshold"
  evaluation_periods = "2"
  metric_name = "UnHealthyHostCount"
  namespace = "AWS/ELB"
  period = "300"
  statistic = "Average"
  threshold = "1"
  dimensions {
    LoadBalancerName = "${aws_elb.elb.name}"
  }
}

Terraform Error

terraform plan

Error: Error running plan: 1 error(s) occurred:

• aws_cloudwatch_metric_alarm.elb_unhealthy_instance_count: 1 error(s) occurred:

• aws_cloudwatch_metric_alarm.elb_unhealthy_instance_count: Resource 'aws_elb.elb' does not have attribute 'name' for variable 'aws_elb.elb.name'

Expected Behavior

I expect the AWS CloudWatch Metric Alarm to be created for the ELB that was provided.

Actual Behavior

Terraform plan errors because of attribute "name" on the aws_elb, which should be automatically defined by Terraform. This same error is generated when "name_prefix" is provided with aws_elb.

The only time this succeeds, is when "name" is provided on the aws_elb.

Steps to Reproduce

1. terraform plan

[bflad]

We do correctly d.Set("name", ...) for other resources that support omitting name/name_prefix, so should be (hopefully) a straightforward bug to fix!

[brumfb]

It looks like it may be related to this commit: 33df43fb. Reverting this commit allowed the name property to be properly resolved, for me. I haven't had a chance to dig into why this commit would affect computed name resolution.

[clebio]

I ran into this today. Lost a good few hours debugging. Thanks to @thatderek for finding this issue. When running terraform plan was getting:

Error: Error running plan: 2 error(s) occurred:

* module.web.aws_autoscaling_group.main: 1 error(s) occurred:

* module.web.aws_autoscaling_group.main: Resource 'aws_elb.main' does not have attribute 'name' for variable 'aws_elb.main.name'
* module.web.aws_load_balancer_policy.ssl_pubkey: 1 error(s) occurred:

* module.web.aws_load_balancer_policy.ssl_pubkey: Resource 'aws_elb.main' does not have attribute 'name' for variable 'aws_elb.main.name'

The terraform we have used

resource "aws_elb" "main" {
  # no "name = " given
  # ...
}

resource "aws_load_balancer_backend_server_policy" "ssl" {
  load_balancer_name = "${aws_elb.main.name}"
  # ...
}


resource "aws_load_balancer_policy" "ssl" {
  load_balancer_name = "${aws_elb.main.name}"
  # ...
}

Adding just name = "${var.name}" in the aws_elb resource is a work-around (but name should be available as an auto-assigned attribute).

[thatderek]

Hope it's not out of order too much to @ @apparentlymart as I think he was the one to review the original code.

Also, I've confirmed that the problem affects versions 1.3 and above (forcing a provider version of 1.2.0 seems to work though).

[apparentlymart]

Hi @lwcbiking et al! Sorry for this weird behavior.

Indeed it does seem like this was an intended casualty of that DiffSuppressFunc change. Unfortunately the team is currently winding down for the holiday break so we don't have @radeksimko around to ask him about this right now, but we'll take a look at it soon to see if there's a more surgical way to achieve what was done in 33df43f.

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!