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

resource/aws_autoscaling_group: Unexpected Removal of Target Group ARNs in version 2.21.0 #9513

Closed
ghost opened this issue Jul 26, 2019 · 10 comments · Fixed by #9518
Closed
Assignees
Labels
bug Addresses a defect in current functionality. regression Pertains to a degraded workflow resulting from an upstream patch or internal enhancement. service/autoscaling Issues and PRs that pertain to the autoscaling service.
Milestone

Comments

@ghost
Copy link

ghost commented Jul 26, 2019

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

0.11.14

Affected Resource(s)

  • aws_autoscaling_group

Terraform Configuration Files

3 resources similar to:

resource "aws_autoscaling_attachment" "application" {
  autoscaling_group_name = "${module.application.application_asg_name}"
  alb_target_group_arn   = "${aws_alb_target_group.application.arn}"
}

Debug Output

Panic Output

Expected Behavior

When planning using 2.20.0, No infrastructure changes are planned. Expectation is that this remains the case with 2.21.0.

Actual Behavior

Using 2.21.0 produced the following plan:

    ~ module.application1.module.application1.aws_autoscaling_group.main
        target_group_arns.#:          "1" => "0"
        target_group_arns.1012598726: "arn:aws:elasticloadbalancing:eu-west-1:xxxxxxxxxxx:targetgroup/application1/3c58ca2c0e49cb1b" => ""
  
    ~ module.application2.module.application2.aws_autoscaling_group.main
        target_group_arns.#:          "2" => "0"
        target_group_arns.3429299186: "arn:aws:elasticloadbalancing:eu-west-1:xxxxxxxxxxx:targetgroup/application2/63ed6bade1545859" => ""
        target_group_arns.703527089:  "arn:aws:elasticloadbalancing:eu-west-1:xxxxxxxxxxx:targetgroup/application2-private/d23ede06f42afcfb" => 

Steps to Reproduce

  1. terraform apply

Important Factoids

References

@github-actions github-actions bot added the needs-triage Waiting for first response or review from a maintainer. label Jul 26, 2019
@edmundcraske
Copy link
Contributor

Not sure if this is caused by #9478 ?

@pabloajz
Copy link

This is happening also to me since today

@tcondeixa
Copy link

tcondeixa commented Jul 26, 2019

happening to me too, when you apply multiple times in a row it is alternating between destroying and creating

@darhon
Copy link

darhon commented Jul 26, 2019

also faced with this problem

@bflad
Copy link
Contributor

bflad commented Jul 26, 2019

Hi folks 👋 Sorry for the unexpected new behavior here. 😖

The change within #9478 to start showing the difference of missing configurations of load_balancers and target_group_arns in the aws_autoscaling_group resource was good in isolation, but does not work in combination with the aws_autoscaling_attachment resource.

While we sort out the best course of action (potentially reverting the change and cutting a 2.21.1 bug fix release), you have a few options to deal with this situation:

  • Update the affected aws_autoscaling_group resource configurations with the lifecycle configuration block ignore_changes argument available to all resources. This should be used where you are expectedly attaching load balancers outside the aws_autoscaling_group resource (e.g. with the aws_autoscaling_attachment resource):
# Compatible in all versions of Terraform

resource "aws_autoscaling_group" "example" {
  # ... other configuration ...

  lifecycle {
    ignore_changes = ["load_balancers", "target_group_arns"]
  }
}

# Terraform 0.12 and later syntax

resource "aws_autoscaling_group" "example" {
  # ... other configuration ...

  lifecycle {
    ignore_changes = [load_balancers, target_group_arns]
  }
}
# Compatible in Terraform 0.10 and later

provider "aws" {
  # ... potentially other configuration ...

  version = "2.20.0"
}

# Terraform 0.12 and later only (applies provider version constraint globally)

terraform {
  # ... potentially other configuration ...

  required_providers {
    # ... potentially other configuration ...

    aws = "2.20.0"
  }
}

If we revert this change, it is likely to occur again with more proper notice in the next major version release of the Terraform AWS Provider, so if possible, we would recommend the ignore_changes configuration change for future proofing.

My apologies again for the unexpected and unannounced change in this behavior. We will update this issue in the next few hours with our plan of action.

@bflad bflad added bug Addresses a defect in current functionality. service/autoscaling Issues and PRs that pertain to the autoscaling service. and removed needs-triage Waiting for first response or review from a maintainer. labels Jul 26, 2019
@bflad bflad self-assigned this Jul 26, 2019
@bflad bflad changed the title Unexpected Removal of Target Group ARNs resource/aws_autoscaling_group: Unexpected Removal of Target Group ARNs in version 2.21.0 Jul 26, 2019
@bflad bflad added the regression Pertains to a degraded workflow resulting from an upstream patch or internal enhancement. label Jul 26, 2019
@nywilken nywilken added this to the v2.21.1 milestone Jul 26, 2019
@blalor
Copy link

blalor commented Jul 26, 2019

If we revert this change, it is likely to occur again with more proper notice in the next major version release of the Terraform AWS Provider, so if possible, we would recommend the ignore_changes configuration change for future proofing.

This will be the suggested route forward when using aws_autoscaling_attachment? I understand there's no real coordination between resources, but that seems odd to me, lie aws_autoscaling_attachment is a 2nd-class resource.

@while1eq1
Copy link

This also affects terraform version: v0.11.11

bflad added a commit that referenced this issue Jul 26, 2019
… target_group_arns Computed behavior

The original change will likely occur in a future major version of the Terraform AWS Provider.

Reference: #9513

Output from acceptance testing:

```
--- PASS: TestAccAWSAutoScalingGroup_WithLoadBalancer_ToTargetGroup (645.69s)
```
@bflad
Copy link
Contributor

bflad commented Jul 26, 2019

Please note that we will be cutting a version 2.21.1 of the Terraform AWS Provider shortly with a fix that reverts the change. Associated pull request: #9518

As mentioned above, this change will likely be redone in a future major version of the Terraform AWS Provider to fix the behavior seen in: #5197

@bflad
Copy link
Contributor

bflad commented Jul 26, 2019

This has been released in version 2.21.1 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests, documentation updates, or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks!

@ghost
Copy link

ghost commented Nov 2, 2019

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!

@ghost ghost locked and limited conversation to collaborators Nov 2, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Addresses a defect in current functionality. regression Pertains to a degraded workflow resulting from an upstream patch or internal enhancement. service/autoscaling Issues and PRs that pertain to the autoscaling service.
Projects
None yet
8 participants