Terraform: Interpolated + count aws_alb_target_group_attachment.target_id showing changes when increasing count or when reprovisioning a single target

[levinse]

Given this config

resource "aws_alb_target_group_attachment" "fe" {
  count = "${var.count}"

  target_group_arn = "${var.alb_target_group_https_arn}"
  target_id = "${element(aws_instance.fe.*.id, count.index)}"
  port = 8080
}

With count = 1 and changing to 2, I expect terraform plan to not show any changes to the existing first resource and to only show a change with the second resource added. However, terraform is showing the following plan output:

-/+ module.fe-app-stg.aws_alb_target_group_attachment.fe.0
    port:             "8080" => "8080"
    target_group_arn: "my ARN value" => "same ARN value"
    target_id:        "my instance id" => "${element(aws_instance.fe.*.id, count.index)}" (forces new resource)

Apparently this will destroy and re-create the first target group attachment when I add a second one - is that how the AWS API works or is that a bug?

[levinse]

@stack72 any updates? The same bug is present when reprovisioning an ALB target without changing the count, e.g. I have two targets and I reprovision one of them, Terraform destroys and recreates both aws_alb_target_group_attachment resources.

[dominics]

Perhaps unrelated, but watch out for the effects of #9948 and #9986 - that issue and PR allow specfiying multiple ECS instances within a single aws_alb_target_group_attachment. Once we have a target property that can take a list, there'd be no need to have multiple aws_alb_target_group_attachment instances; just the one that gets modified when the list changes.

[edsonmarquezani]

I've run into the same issue. We use to create our instances with count, and do every other dependency (DNS, EBS attachments, etc) based on it. But when it comes to load balancer attachments, it won't work, except for the first time, because any change in the count number will destroy and create again every attachment, taking the service temporarily down, which is something we can't afford. I'm not sure this is a bug or some design mistake, but it certainly shouldn't behave like that.
Is there any changes of it being fixed in the near future?

[levinse]

@stack72 @mitchellh any updates on this one?

[mitchellh]

Not at the moment, its something we're well aware of but don't have a clear way to address it currently. We're working towards it, though.

[atyndall]

We're also experiencing this bug, makes it very difficult to do planning around web nodes behind a load balancer.

[levinse]

Just following up as this is still impacting us...

[derFunk]

@atyndall Exactly my use case as well! Encountered the same issue.

[ivanfetch]

What work-arounds are others using to avoid unnecessarily recreating target group attachments, until this bug is resolved and it is possible to use count for attachments?

I'm exploring three possibilities:

(1) I'm tempted to use ignore_changes = ["target_id"], as I'm already doing something similar to avoid recreating volume attachments to EC2 instances. IF using ignore_changes we'll need to remember to also taint the target group attachment if there are any changes to its instance - perhaps a reasonable hoop to jump through for now.

(2) Even creating individual alb_target_group_attachment resources and referencing a single element from a splatted EC2 module output, causes the target group attachment to get unnecessarily recreated. For example:

# My EC2 module has an output which is a splat of instance IDs, instantiated as Appname_servers here.
resource "aws_alb_target_group_attachment" "lb_target_attachment_inst0" {
  # Single attachment, not using count, still doesn't avoid recreation.
  target_group_arn = "${module.AppName_lb.target_group_arn}"
  target_id = "${module.AppName_servers.id[0]}"
}

(3) I also tried using create_before_destroy on the target group attachment, but the destroy seems to cause the recently recreated attachment to be drained and removed from the target group, leaving me with no attachments. :) This may be a bug in that create_before_destroy should wait for the deleted attachment to be drained before creating the new one.

Thanks for any help deciding on a most reasonable work-around.

[dohoangkhiem]

My situation might be a little bit different to this: count is not changed but try deregistering one instance from target group in EC2 Console, running terraform plan and it won't recognize the attachment is deleted so the plan shows nothing.

I found this https://github.com/terraform-providers/terraform-provider-aws/issues/971, which is exactly the problem I got.

[hashibot[bot]]

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.