intermittent issue with aws_appautoscaling_target and aws_appautoscaling_policy creation #427
Comments
|
I am still experiencing the issue in Terraform v0.10.2. Creating an aws_appautoscaling_policy fails with As can be seen by the following log: The aws_appautoscaling_target is created before the policy but the policy creation still fails. Re running |
|
I can confirm in 0.10.7 Added a depends_on block to no avail.:
|
|
I have an absolutely horrifying hack that fixes this for now. Read it and weep: |
|
Any updates on this? Also running into this? |
|
I'm running into this issue with Terraform version v.0.11.0 Edit: i had typo in my policy |
|
Hi I just got hit by this issue with Terraform v0.11.5
And just like you, I re-ran Thomas |
…d` updates and ignore `ObjectNotFoundException` on deletion References: * #7963 * #5747 * #538 * #486 * #427 * #404 Previously the documentation recommended an ECS setup that used `depends_on` combined with an updateable `resource_id` attribute, that could introduce very subtle bugs in the operation of the `aws_appautoscaling_policy` resource when the either underlying Application AutoScaling Target or target resource (e.g. ECS service) was updated or recreated. Given the scenario with an `aws_appautoscaling_policy` configuration: * No direct attributes references to its `aws_appautoscaling_target` parent (usage with or without `depends_on` is inconsequential except without its usage in this case, it would generate errors that the target does not exist due to lack of proper ordering) * `resource_id` directly references the target resource (e.g. an ECS service) * The underlying `resource_id` target resource (e.g. an ECS service) is pointed to a new location or the resource is recreated The `aws_appautoscaling_policy` resource would plan as an resource update of just the `resource_id` attribute instead of resource recreation. Several consquences could occur in this situation depending on the exact ordering and Terraform configuration: * Since the Application AutoScaling Policy API only supports a `PUT` type operation for creation and update, a new policy would create successfully (given the Application AutoScaling Target was already in place), hiding any coding errors that might have been found if it was attempting to update a non-created policy * Usage of only `depends_on` to reference the Application AutoScaling Target could miss creating the Application AutoScaling Policy in a single apply since `depends_on` is purely for ordering * The lack of Application AutoScaling Policy deletion could leave dangling policies on the previous Application AutoScaling Target unless it was updated (which it correctly recreates the resource in Terraform) or otherwise deleted * The Terraform resource would not know to properly update the value of other computed attributes during plan, such as `arn`, potentially only noticing these attribute values as a new applied value different from the planned value These situations could surface as Terraform bugs in multiple ways: * In friendlier cases, a second apply would be required to create the missing policy or update downstream computed references * In worse cases, Terraform would report errors (depending on the Terraform version) such as `Resource 'aws_appautoscaling_policy.example' does not have attribute 'arn'` and `diffs didn't match during apply` for downstream attribute references to those computed attributes To prevent these situations, the `ResourceId` of the Application AutoScaling Policy needs be treated as part of the API object ID, similar to Application AutoScaling Targets, and marked `ForceNew: true` in the Terraform resource schema. We also ensure the documentation examples always recommend direct references to the upstream `aws_appautoscaling_target` instead of using `depends_on` so Terraform properly handles recreations when necessary, e.g. ```hcl resource "aws_appautoscaling_target" "example" { # ... other configuration ... } resource "aws_appautoscaling_policy" "example" { # ... other configuration ... resource_id = "${aws_appautoscaling_target.example.resource_id}" scalable_dimension = "${aws_appautoscaling_target.example.scalable_dimension}" service_namespace = "${aws_appautoscaling_target.example.service_namespace}" } ``` During research of this bug, it was also similarly discovered that the `aws_appautoscaling_policy` resource did not gracefully handle external deletions of the Application AutoScaling Policy without a refresh or potential deletion race conditions with the following error: ``` ObjectNotFoundException: No scaling policy found for service namespace: ecs, resource ID: service/tf-acc-test-9190521664283069857/tf-acc-test-9190521664283069857, scalable dimension: ecs:service:DesiredCount, policy name: tf-acc-test-9190521664283069857 ``` We include ignoring this potential error on deletion as part of the comprehesive solution to ensuring resource recreations are successful. Output from acceptance testing before code update: ``` --- FAIL: TestAccAWSAppautoScalingPolicy_ResourceId_ForceNew (54.69s) testing.go:538: Step 1 error: After applying this step, the plan was not empty: DIFF: UPDATE: aws_cloudwatch_metric_alarm.test alarm_actions.3359603714: "arn:aws:autoscaling:us-west-2:--OMITTED--:scalingPolicy:065d03ea-a7a4-4047-9a43-c92ec1871170:resource/ecs/service/tf-acc-test-2456603151506624334/tf-acc-test-2456603151506624334-1:policyName/tf-acc-test-2456603151506624334" => "" alarm_actions.4257611624: "" => "arn:aws:autoscaling:us-west-2:--OMITTED--:scalingPolicy:cdc6d280-8a93-4c67-9790-abb47fd167c6:resource/ecs/service/tf-acc-test-2456603151506624334/tf-acc-test-2456603151506624334-2:policyName/tf-acc-test-2456603151506624334" ``` Output from acceptance testing: ``` --- PASS: TestAccAWSAppautoScalingPolicy_disappears (26.48s) --- PASS: TestAccAWSAppautoScalingPolicy_scaleOutAndIn (28.53s) --- PASS: TestAccAWSAppautoScalingPolicy_ResourceId_ForceNew (43.25s) --- PASS: TestAccAWSAppautoScalingPolicy_basic (46.47s) --- PASS: TestAccAWSAppautoScalingPolicy_spotFleetRequest (61.26s) --- PASS: TestAccAWSAppautoScalingPolicy_dynamoDb (115.02s) --- PASS: TestAccAWSAppautoScalingPolicy_multiplePoliciesSameResource (116.06s) --- PASS: TestAccAWSAppautoScalingPolicy_multiplePoliciesSameName (116.80s) ```
|
Hi folks 👋 Sorry for the unexpected behavior here. It turns out there was a very subtle bug that prevented proper recreation of Application AutoScaling Policies when only the Even without upgrading your Terraform AWS Provider to the newer version, you may be able to workaround the original issue with a simple configuration update. Using direct references to the relevant resource "aws_appautoscaling_target" "example" {
# ... other configuration ...
}
resource "aws_appautoscaling_policy" "example" {
# ... other configuration ...
resource_id = "${aws_appautoscaling_target.example.resource_id}"
scalable_dimension = "${aws_appautoscaling_target.example.scalable_dimension}"
service_namespace = "${aws_appautoscaling_target.example.service_namespace}"
}If you are still having trouble after upgrading to version 2.3.0 of the Terraform AWS Provider (when its released) and with a configuration looking similar to the above, please create a new GitHub issue with the relevant details from the issue template and we can further triage. Thanks! |
|
This has been released in version 2.3.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. |
|
Oddly I've just hit this issue in one of our temporary environments when the target group changed. We're using my fork from #6314 which is based off 2.4.0 (with my change applied over the top) and the above change in https://github.com/terraform-providers/terraform-provider-aws/pull/7982/files looks good to me so I'm not too sure why this has failed. Partial output from the failed apply: |
|
Oh, derp, misread the change. I guess we need to catch the |
|
Thanks for the additional fix here @tomelliff, which looks more appropriate for this particular issue. I've updated the milestone here to version 2.6.0 since it will likely be more helpful. Version 2.6.0 is planned to ship later today. |
|
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
locked and limited conversation to collaborators
This issue was originally opened by @brikis98 as hashicorp/terraform#10737. It was migrated here as part of the provider split. The original body of the issue is below.
Terraform Version
Terraform v0.7.7
Affected Resource(s)
Terraform Configuration Files
Expected Behavior
The auto scaling policy and target are both created successfully.
Actual Behavior
Intermittently, you get an error like this:
If you re-run
terraform apply, the error usually goes away.Steps to Reproduce
terraform applyImportant Factoids
If you re-run
terraform apply, sometimes multiple times, it works. I suspect this is a classic issue with the fact that AWS is asynchronous and eventually consistent and Terraform is not properly waiting for theaws_appautoscaling_targetresource to be created.The text was updated successfully, but these errors were encountered: