Tags are not applied, instances are not placed in ELB

[levinotik]

I'm using binaries built directly from master and it seems that at random times, tags are not applied to AWS instances and instances are not placed in ELBs. I experienced this same behavior with 0.2.2 as well as 0.3.0

[mitchellh]

Can you narrow down "at random times" to a repro case? It is hard for us to diagnose the issue properly without a set of steps to repro it. Even if the set of steps sometimes works and sometimes doesn't, it would help.

[mitchellh]

I believe this is fixed with #464. I didn't get an answer from you (it has only been 6 hours after all), but based on what I would expect to be the behavior before the bug in #464 was fixed, the behavior you saw is fully in line with it. Grab master and let me know if you still see it.

[levinotik]

@mitchellh Thanks a lot, ya'll seriously rock. Hopefully, it's a moot point now, but I'm trying to get some more color on this. If it helps, all I'm doing is applying an unchanged plan with a new ami id. My plan looks like this:

resource "aws_instance" "website1" {
    ami = "${var.ami_id}"
    associate_public_ip_address = true
    instance_type = "m1.small"
    subnet_id = "subnet-0be8c24d"
    security_groups = ["sg-62659f07"]
    key_name = "gw-key-pair"
    tags {
      Name = "website"
      Env = "prod"
     }
}

resource "aws_instance" "website2" {
    ami = "${var.ami_id}"
    associate_public_ip_address = true
    instance_type = "m1.small"
    subnet_id = "subnet-0be8c24d"
    security_groups = ["sg-62659f07"]
    key_name = "gw-key-pair"
    tags {
      Name = "website"
      Env = "prod"
     }
}

resource "aws_elb" "website" {
  name = "foo-elb-prod"
  subnets = ["subnet-0be8c24d"]
  security_groups = ["sg-62659f07"]


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

  health_check {
    healthy_threshold = 2
    unhealthy_threshold = 5
    timeout = 3
    target = "HTTP:8080/healthcheck"
    interval = 30
  }

  instances = ["${aws_instance.website1.id}", "${aws_instance.website2.id}"]
}

resource "aws_route53_record" "website" {
   zone_id = "Z36X3B64AO2X4F"
   name = "myrecord.foo.com"
   type = "CNAME"
   ttl = "300"
   records = ["${aws_elb.website.dns_name}"]
}

More times than not, the tags aren't applied and the instances don't get placed in the ELB. Either way, thanks again and I'll try a build from master.

[mitchellh]

Thanks for the config. If you still see the issue with 0.3.1 let me know.

[levinotik]

@mitchellh The issue with the tags seems to be fixed, but the instances are still not being placed into the ELB.

[mitchellh]

Great! I'll reopen for the ELB

[levinotik]

I was just asking in the mailing list about how to ensure resources are created before the old ones are destroyed and @pearkes pointed me to the lifecycle { create_before_destroy = true } syntax. While I was looking into this, I executed a terraform plan to see what was going to happen and I noticed that only my instances had a plan for being destroyed and created and there was no entry indicating that the ELB was going to be updated. I think this is consistent with the new instances not being added to the ELB. Also, probably a separate issue, but the lifecycle hook didn't seem to have any effect and my old instances were destroyed prior to creating the new ones. If it's helpful, here's the output of terraform plan

Refreshing Terraform state prior to plan...

aws_instance.website2: Refreshing state... (ID: i-bdcd8bb2)
aws_instance.website1: Refreshing state... (ID: i-b1cd8bbe)
aws_elb.website: Refreshing state... (ID: mywebsite-elb-prod)
aws_route53_record.website: Refreshing state... (ID: Z36X3B64AO2X4F_mywebsite.com_CNAME)

The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

-/+ aws_instance.website1
    ami:                         "ami-d10648e1" => "ami-d33e70e3" (forces new resource)
    associate_public_ip_address: "true" => "1"
    availability_zone:           "us-west-2c" => "<computed>"
    instance_type:               "m1.small" => "m1.small"
    key_name:                    "gw-key-pair" => "gw-key-pair"
    private_dns:                 "ip-10-0-0-120.us-west-2.compute.internal" => "<computed>"
    private_ip:                  "10.0.0.120" => "<computed>"
    public_dns:                  "xxx.us-west-2.compute.amazonaws.com" => "<computed>"
    public_ip:                   "xxx" => "<computed>"
    security_groups.#:           "1" => "1"
    security_groups.0:           "sg-62659f07" => "sg-62659f07"
    subnet_id:                   "subnet-0be8c24d" => "subnet-0be8c24d"
    tags.Env:                    "prod" => "prod"
    tags.Name:                   "website" => "website"

-/+ aws_instance.website2
    ami:                         "ami-d10648e1" => "ami-d33e70e3" (forces new resource)
    associate_public_ip_address: "true" => "1"
    availability_zone:           "us-west-2c" => "<computed>"
    instance_type:               "m1.small" => "m1.small"
    key_name:                    "gw-key-pair" => "gw-key-pair"
    private_dns:                 "ip-10-0-0-74.us-west-2.compute.internal" => "<computed>"
    private_ip:                  "10.0.0.74" => "<computed>"
    public_dns:                  "xxx.us-west-2.compute.amazonaws.com" => "<computed>"
    public_ip:                   "xxx" => "<computed>"
    security_groups.#:           "1" => "1"
    security_groups.0:           "sg-62659f07" => "sg-62659f07"
    subnet_id:                   "subnet-0be8c24d" => "subnet-0be8c24d"
    tags.Env:                    "prod" => "prod"
    tags.Name:                   "website" => "website"

Parenthetically, I can just use count = 2 to create two instances instead of creating two separate resource blocks for the instances, right?

[joescii]

I encountered this exact issue while mimicking some of @levinotik's work. I managed a workaround by always renaming the ELB to force it to rebuild. For anyone in need, this is how I did it:

In my shell script, I create a timestamp to append to the name and pass it in as a var:

timestamp=`date +"%Y%m%d%H%M%S"`
ELB_NAME=elb-${timestamp}
./terraform/terraform apply  \
  -var "elb_name=${ELB_NAME}" 

Then of course, I add it to my variables tr file and reference it accordingly:

// variables.tr
variable "elb_name" {}

// infra.tr
resource "aws_elb" "my-elb" {
  name = "${var.elb_name}"
  // ...
}

[phinze]

Hey folks - I'm making a sweep of old issues. We change up tags and ELB instance registration on a near-daily basis in our own environments, and we've seen no troubles in recent versions of Terraform.

If any of you are still experiencing issues, would you mind filing a fresh issue w/ repro steps? Thanks!

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