feat: Add support for predictive autoscaling policies

[zahorniak]

Description

• Added support for predefined metrics

  • predefined_load_metric_specification
  • predefined_metric_pair_specification
  • predefined_scaling_metric_specification

• Added support for customized metrics

  • customized_capacity_metric_specification
  • customized_load_metric_specification
  • customized_scaling_metric_specification

Motivation and Context

• Closes Add support for predictive_scaling_policy_configuration configuration block for service autoscaling #352

Breaking Changes

No

How Has This Been Tested?

• I have updated at least one of the examples/* to demonstrate and validate my change(s)
• I have tested and validated these changes using one or more of the provided examples/* projects

• I have executed pre-commit run -a on my pull request

[zahorniak]

I want to address a naming inconsistency across target_tracking_scaling_policy_configuration.customized_metric_specification.dimensions and customized_*_specification.metric_data_query.metric_stat.metric.dimension:

• https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/appautoscaling_policy#dimensions-1
• https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/appautoscaling_policy#dimension-1

Target tracking using dimensionS while all predictive scaling metrics use dimension naming. In the module configuration, I decided to use dimensions everywhere to keep the same object structure as you already have for target tracking policies:

metrics = optional(list(object({
  expression = optional(string)
  id         = string
  label      = optional(string)
  metric_stat = optional(object({
    metric = object({
      dimensions = optional(list(object({
        name  = string
        value = string
      })))
      metric_name = string
      namespace   = string
    })
    stat = string
    unit = optional(string)
  }))
  return_data = optional(bool)
})))

I believe it can help prevent mistakes or typos when using multiple scaling policies for a single service.

[bryantbiggs]

I want to address a naming inconsistency across target_tracking_scaling_policy_configuration.customized_metric_specification.dimensions and customized_*_specification.metric_data_query.metric_stat.metric.dimension:

* [registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/appautoscaling_policy#dimensions-1](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/appautoscaling_policy#dimensions-1)

* [registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/appautoscaling_policy#dimension-1](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/appautoscaling_policy#dimension-1)

Target tracking using dimensionS while all predictive scaling metrics use dimension naming. In the module configuration, I decided to use dimensions everywhere to keep the same object structure as you already have for target tracking policies:

metrics = optional(list(object({
  expression = optional(string)
  id         = string
  label      = optional(string)
  metric_stat = optional(object({
    metric = object({
      dimensions = optional(list(object({
        name  = string
        value = string
      })))
      metric_name = string
      namespace   = string
    })
    stat = string
    unit = optional(string)
  }))
  return_data = optional(bool)
})))

I believe it can help prevent mistakes or typos when using multiple scaling policies for a single service.

thats due to the API - https://github.com/hashicorp/terraform-provider-aws/blob/782cca0e2343caa5ee37950708d563ef25a95aa7/internal/service/appautoscaling/policy.go#L249

vs https://github.com/hashicorp/terraform-provider-aws/blob/782cca0e2343caa5ee37950708d563ef25a95aa7/internal/service/appautoscaling/policy.go#L451

We usually try to match the underlying API since thats the easiest and least confusing, only deviating in select scenarios

[bryantbiggs]

great start! few changes to the structure and definitions

[zahorniak]

@bryantbiggs, I tried to apply all your suggestions. The only one I didn't understand is: #361 (comment).

[bryantbiggs]

looks great, thank you for the contribution!

[antonbabenko]

This PR is included in version 6.7.0 🎉