$ terraform -v
Terraform v0.11.8
+ provider.archive v1.0.0
+ provider.aws v1.40.0
+ provider.template v1.0.0
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*"]
}
}
I'll provide this if needed/requested.
Implicit action order should match the previous 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.
terraform applyWe 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).
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?
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.
Potential fix submitted: #6119
I checked it and 1 seems to be the appropriate default for this - version pinning to 1.39.0 the change disappears so I donβt think it was changed manually.
Sent from my iPhone
On Oct 10, 2018, at 5:22 PM, Brian Flad notifications@github.com wrote:
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?
β
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
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.
Potential fix submitted: #6119
Confirmed fixed - thank you!
@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.
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.
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 (https://github.com/terraform-providers/terraform-provider-aws/issues/6116#issuecomment-428779202) 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.
For those that are interested, followup PR to make order completely optional: #6124
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.
Thanks @bflad, Terraform is still crashing with 1.41.0 so I'm going to submit the logs in the morning.
@djk okay -- I'd check if its similar to #6171 otherwise open a new issue for proper tracking π
@bflad Actually that does look exactly like it. Thanks for linking me to it!
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!
Most helpful comment
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 (https://github.com/terraform-providers/terraform-provider-aws/issues/6116#issuecomment-428779202) can be used in the meantime.
I also have a followup pull request to make
ordercompletely optional (based on the Terraform configuration ordering), which will be submitted very shortly.