-
Notifications
You must be signed in to change notification settings - Fork 9.2k
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_appautoscaling_policy: Remove unimplemented alarms attribute #11494
Conversation
…bute Reference: #9954 Previously: ``` /Users/bflad/src/github.com/terraform-providers/terraform-provider-aws/aws/resource_aws_appautoscaling_policy.go:333:18: R004: ResourceData.Set() incompatible value type: []*github.com/aws/aws-sdk-go/service/applicationautoscaling.Alarm ``` The `alarms` attribute was never actually implemented: - `d.Set()` never would have set anything in the Terraform state due to silently ignoring the error above, so Terraform configuration references to the attribute would always have been invalid trying to reference a non-existent resource attribute - Configuring `alarms` in a configuration was never valid as it would not have done anything (CloudWatch Alarms are a read-only property of Application Auto Scaling Policies) - Not acceptance tested - Not documented Due to these conditions and since there are no associated bug reports or feature requests for this attribute, it feels safe to bypass our normal attribute deprecation/removal process and just remove the errant attribute definition from the schema. If desired in the future, this could be implemented as a `Computed: true` only attribute. Output from acceptance testing: ``` --- PASS: TestAccAWSAppautoScalingPolicy_dynamoDb (34.67s) --- PASS: TestAccAWSAppautoScalingPolicy_multiplePoliciesSameName (40.33s) --- PASS: TestAccAWSAppautoScalingPolicy_multiplePoliciesSameResource (41.44s) --- PASS: TestAccAWSAppautoScalingPolicy_disappears (72.83s) --- PASS: TestAccAWSAppautoScalingPolicy_basic (78.93s) --- PASS: TestAccAWSAppautoScalingPolicy_spotFleetRequest (81.81s) --- PASS: TestAccAWSAppautoScalingPolicy_ResourceId_ForceNew (87.53s) --- PASS: TestAccAWSAppautoScalingPolicy_scaleOutAndIn (88.80s) ```
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
--- PASS: TestValidateAppautoscalingPolicyImportInput (0.00s)
--- PASS: TestAccAWSAppautoScalingPolicy_dynamoDb (18.33s)
--- PASS: TestAccAWSAppautoScalingPolicy_multiplePoliciesSameResource (20.16s)
--- PASS: TestAccAWSAppautoScalingPolicy_multiplePoliciesSameName (20.89s)
--- PASS: TestAccAWSAppautoScalingPolicy_basic (46.60s)
--- PASS: TestAccAWSAppautoScalingPolicy_spotFleetRequest (60.94s)
--- PASS: TestAccAWSAppautoScalingPolicy_ResourceId_ForceNew (61.40s)
--- PASS: TestAccAWSAppautoScalingPolicy_disappears (65.26s)
--- PASS: TestAccAWSAppautoScalingPolicy_scaleOutAndIn (70.00s)
This has been released in version 2.46.0 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 or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks! |
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! |
Community Note
Reference: #9954
Release note for CHANGELOG:
Previously:
The
alarms
attribute was never actually implemented:d.Set()
never would have set anything in the Terraform state due to silently ignoring the error above, so Terraform configuration references to the attribute would always have been invalid trying to reference a non-existent resource attributealarms
in a configuration was never valid as it would not have done anything (CloudWatch Alarms are a read-only property of Application Auto Scaling Policies)Due to these conditions and since there are no associated bug reports or feature requests for this attribute, it feels safe to bypass our normal attribute deprecation/removal process and just remove the errant attribute definition from the schema. If desired in the future, this could be implemented as a
Computed: true
only attribute.Output from acceptance testing: