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

aws_lb_listener_rule action implicit order is broken #6116

Closed
devonbleak opened this issue Oct 10, 2018 · 15 comments · Fixed by #6119
Closed

aws_lb_listener_rule action implicit order is broken #6116

devonbleak opened this issue Oct 10, 2018 · 15 comments · Fixed by #6119
Labels
bug Addresses a defect in current functionality. service/elbv2 Issues and PRs that pertain to the elbv2 service.
Milestone

Comments

@devonbleak
Copy link
Contributor

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

$ terraform -v
Terraform v0.11.8
+ provider.archive v1.0.0
+ provider.aws v1.40.0
+ provider.template v1.0.0

Affected Resource(s)

  • aws_lb_listener_rule

Terraform Configuration Files

resource "aws_lb_listener_rule" "wiki_synchrony_prod" {
  listener_arn = "${aws_lb_listener.atlassian_stack_prod.arn}"
  priority     = 2

  action {
    type             = "forward"
    target_group_arn = "${aws_lb_target_group.wiki_synchrony_prod.arn}"
  }

  condition {
    field  = "host-header"
    values = ["wiki.company.com"]
  }

  condition {
    field  = "path-pattern"
    values = ["/synchrony-home*"]
  }
}

Debug Output

I'll provide this if needed/requested.

Expected Behavior

Implicit action order should match the previous behavior

Actual Behavior

Implicit action order is being calculated as 0 when aws provider is updated to 1.40.0 which is invalid:

Terraform will perform the following actions:

  ~ aws_lb_listener_rule.wiki_synchrony_prod
      action.0.order: "1" => "0"


Plan: 0 to add, 1 to change, 0 to destroy.
$ terraform apply test.plan
aws_lb_listener_rule.wiki_synchrony_prod: Modifying... (ID: arn:aws:elasticloadbalancing:us-west-2:...f00e/b4ba2f49e8d7bcaa/45dc05831bc3a8cd)
  action.0.order: "1" => "0"

Error: Error applying plan:

1 error(s) occurred:

* aws_lb_listener_rule.wiki_synchrony_prod: 1 error(s) occurred:

* aws_lb_listener_rule.wiki_synchrony_prod: Error modifying LB Listener Rule: InvalidParameter: 1 validation error(s) found.
- minimum field value of 1, ModifyRuleInput.Actions[0].Order.


Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

Steps to Reproduce

  1. terraform apply

Important Factoids

We actually have multiple similar rules on this listener but this is the only one impacted. We even have a nearly identical rule for QA that is not impacted (slightly different host header condition).

References

@bflad bflad added bug Addresses a defect in current functionality. service/elbv2 Issues and PRs that pertain to the elbv2 service. labels Oct 11, 2018
@bflad
Copy link
Contributor

bflad commented Oct 11, 2018

This is very strange behavior indeed! Sorry for the trouble. 😅

Its not showing up in our acceptance testing, but our acceptance testing is also freshly creating these resources each time. Were any of the affected resources adjusted via the AWS console by chance?

@bflad bflad added this to the v1.41.0 milestone Oct 11, 2018
@bflad
Copy link
Contributor

bflad commented Oct 11, 2018

Until a more permanent fix is implemented, there are two workarounds for this scenario:

Adding the configuration to match the API response, e.g.

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

  action {
    # ... other configuration ...

    order = 1
  }
}

Or, using ignore_changes in your Terraform configuration, e.g.

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

  lifecycle {
    ignore_changes = ["action.0.order"]
  }
}

There is also a good chance that aws_lb_listener might exhibit the same behavior with its default_action order argument as well.

@bflad
Copy link
Contributor

bflad commented Oct 11, 2018

Potential fix submitted: #6119

@devonbleak
Copy link
Contributor Author

devonbleak commented Oct 11, 2018 via email

@bflad
Copy link
Contributor

bflad commented Oct 11, 2018

There seems to be two scenarios occurring: the API returning 1 (which logically makes sense) and the API not returning a value, which defaults to 0. In all the existing acceptance tests, the API is not returning a value. Version 1.39.0 did not read this attribute from the API, so the difference will only be seen in 1.40.0 or later.

@devonbleak
Copy link
Contributor Author

Potential fix submitted: #6119

Confirmed fixed - thank you!

@djk
Copy link

djk commented Oct 11, 2018

@bflad is there any chance of the fix being merged and released quickly or will it wait until the next provider release? Was waiting for the Cognito LB auth functionality with baited breath and hit a variation of the problem in this issue. It actually caused Terraform to crash in my experience and was definitely when "order = X" was added to the lb_listener resource. It worked up to that point.

@prog893
Copy link

prog893 commented Oct 11, 2018

We can confirm the same happening in our use case after editing listener rules in console:

resource "aws_alb_listener_rule" "rule_12" {
  listener_arn = "${aws_alb_listener.listener.arn}"
  priority     = "12"

  action {
    target_group_arn = "${data.aws_alb_target_group.target.arn}"
    type             = "forward"
  }

  condition {
    field  = "path-pattern"
    values = ["/somepath/*"]
  }
}

Running plan on configuration using rules like above in v1.39 results in No changes; doing the same on v1.40 results in Terraform trying to change order from 1 to 0. Which on apply results in following:

Error: Error applying plan:

1 error(s) occurred:

* aws_alb_listener_rule.rule_12: 1 error(s) occurred:

* aws_alb_listener_rule.rule_12: Error modifying LB Listener Rule: InvalidParameter: 1 validation error(s) found.
- minimum field value of 1, ModifyRuleInput.Actions[0].Order.

@bflad
Copy link
Contributor

bflad commented Oct 11, 2018

I merged the initial fix for this which is schedule to be released with version 1.41.0 of the AWS provider, likely middle of next week (on our normal weekly release cadence). Version 1.39.0 or the workarounds mentioned here (#6116 (comment)) can be used in the meantime.

I also have a followup pull request to make order completely optional (based on the Terraform configuration ordering), which will be submitted very shortly.

@bflad
Copy link
Contributor

bflad commented Oct 11, 2018

For those that are interested, followup PR to make order completely optional: #6124

@bflad
Copy link
Contributor

bflad commented Oct 18, 2018

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

@djk
Copy link

djk commented Oct 18, 2018

Thanks @bflad, Terraform is still crashing with 1.41.0 so I'm going to submit the logs in the morning.

@bflad
Copy link
Contributor

bflad commented Oct 18, 2018

@djk okay -- I'd check if its similar to #6171 otherwise open a new issue for proper tracking 👍

@djk
Copy link

djk commented Oct 19, 2018

@bflad Actually that does look exactly like it. Thanks for linking me to it!

@ghost
Copy link

ghost commented Apr 2, 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 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 Apr 2, 2020
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. service/elbv2 Issues and PRs that pertain to the elbv2 service.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants