Make min/max values in SLO resources settable to "infinity"

[etruong42]

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. If the issue is assigned to the "modular-magician" user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If the issue is assigned to a user, that user is claiming responsibility for the issue. If the issue is assigned to "hashibot", a community member has claimed the issue already.

Description

Make min/max values settable to "infinity". Documentation prior to the change at GoogleCloudPlatform/magic-modules#7571 indicated that this is possible, but it is not. #9453 was filed that suggested this is desirable. The current workaround is to use a very large number in place of infinity (1.7976931348623157e+308) or a very small number in place of -infiniy (-1.7976931348623157e+308)

New or Affected Resource(s)

• google_monitoring_slo

Potential Terraform Configuration

resource "google_monitoring_slo" "my_slo" {
    service = google_monitoring_service.my_service.service_id
    #slo_id = "0HqJ_9KeQY2zsy8n4fb4Cw"
    goal = 0.8
    calendar_period = "DAY"
      request_based_sli {
    distribution_cut {
          distribution_filter = "metric.type=\"custom.googleapis.com/opencensus/grpc.io/client/roundtrip_latency/cumulative\" resource.type=\"k8s_container\""
          range {
            max = "infinity"
            min = "-infinity"
          }
        }
  }
    display_name = "80% - Distribution Cut - Calendar day"
}

References

• b/276340305

[melinath]

This may be standard behavior that we want to solve for all Double fields - currently 89 in MMv1. go/proto3#json

Handling for all fields would likely need to be a separate ticket, unless this ends up being complex enough it needs changes to the core compilation engine anyway. However, whatever behavior we use for this field should be something we would be happy to use for all similar fields.