Validation pattern is narrower than actually used/generated for `google_monitoring_custom_service` and SLO.

[pokutuna]

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 an 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 an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to hashibot, a community member has claimed the issue already.

Terraform Version

Terraform v1.5.7
on darwin_arm64
+ provider registry.terraform.io/hashicorp/google v4.82.0

Affected Resource(s)

• google_monitoring_custom_service
• google_monitoring_slo

Terraform Configuration Files

terraform {
  required_version = "1.5.7"

  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "4.82.0"
    }
  }

  backend "local" {
    path = "terraform.tfstate"
  }
}

# my Google Cloud project
provider "google" {
  project = "pokutuna-playground"
}

# to be imported
import {
  to = google_monitoring_custom_service.example
  id = "projects/my-project/services/gs-ReZdgRiuY5DWEldJnSA"
}
import {
  to = google_monitoring_slo.example
  id = "projects/my-project/services/gs-ReZdgRiuY5DWEldJnSA/serviceLevelObjectives/c3nU6dECTzSjFSEmMCyRyA"
}

Debug Output

The following gist includes the output of the operations I actually executed in my Google Cloud project.

1. $ cat main.tf
2. $ TF_LOG=DEBUG terraform plan -generate-config-out=imported.tf
3. $ cat imported.tf
4. $ TF_LOG=DEBUG terraform plan

https://gist.github.com/pokutuna/0f84c03e0eb18ac26a91b031afa1a419

Panic Output

N/A

Expected Behavior

The actual existing service_id and slo_id do not trigger validation errors.

Actual Behavior

When running plan with import, or apply after import, the following validation errors are printed.
(Other errors are also included, but they are not mentioned in this issue.)

│ Error: "service_id" ("gs-ReZdgRiuY5DWEldJnSA") doesn't match regexp "^[a-z0-9\\-]+$"
│
│   with google_monitoring_custom_service.example,
│   on imported.tf line 8, in resource "google_monitoring_custom_service" "example":
│    8:   service_id   = "gs-ReZdgRiuY5DWEldJnSA"

│ Error: "slo_id" ("c3nU6dECTzSjFSEmMCyRyA") doesn't match regexp "^[a-z0-9\\-]+$"
│
│   with google_monitoring_slo.example,
│   on imported.tf line 25, in resource "google_monitoring_slo" "example":
│   25:   slo_id              = "c3nU6dECTzSjFSEmMCyRyA"

The service_id and slo_id are automatically generated when created from the console.
The IDs I used in the example were also automatically generated.

In other words, it's validating with a pattern that's narrower than what Cloud Monitoring actually generates.

Steps to Reproduce

1. Define a custom service and SLO on the Cloud Monitoring console.
2. Describe the defined resources in the import block.
3. Execute the steps included in the log.

• $ cat main.tf
• $ TF_LOG=DEBUG terraform plan -generate-config-out=imported.tf
• $ cat imported.tf
• $ TF_LOG=DEBUG terraform plan

Important Factoids

There's nothing special about my account.
I'm using the Application Default Credentials created with gcloud auth application-default login.

I suspect that the pattern ^[a-z0-9\\-]+$ is from the following API documentation.

• Method: services.create
• Method: services.serviceLevelObjectives.create

I believe the pattern in these documents are also incorrect (I've provided feedback on it).

The pattern that's actually working on Cloud Monitoring can be obtained from the API error.

$ curl -X POST -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" "https://monitoring.googleapis.com/v3/projects/$GOOGLE_PROJECT/services?serviceId=%F0%9F%A5%BA"
{
  "error": {
    "code": 400,
    "message": "Resource names must match pattern `^[a-zA-Z0-9-_:.]+$`. Got value \"🥺\"",
    "status": "INVALID_ARGUMENT"
  }
}

Therefore, ^[a-zA-Z0-9-_:.]+$ is the pattern that represents actual possible IDs.
We can actually call these API to create a custom service and slo with the ID prefix:lower_UPPER-01.23.

$ export GOOGLE_PROJECT=pokutuna-playground
$ export ACCEPTABLE_ID=prefix:lower_UPPER-01.23
$ curl -X POST -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" "https://monitoring.googleapis.com/v3/projects/$GOOGLE_PROJECT/services?serviceId=$ACCEPTABLE_ID" -d '{"custom":{}}' -H 'Content-Type: application/json'
> {
>   "name": "projects/744005832574/services/prefix:lower_UPPER-01.23",
>   "custom": {},
>   "telemetry": {}
> }
$ curl -X POST -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" -H 'Content-Type: application/json' "https://monitoring.googleapis.com/v3/projects/$GOOGLE_PROJECT/services/$ACCEPTABLE_ID/serviceLevelObjectives?serviceLevelObjectiveId=$ACCEPTABLE_ID" -d @- <<JSON
{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        distributionFilter: "metric.type=\"appengine.googleapis.com/http/server/response_latencies\" resource.type=\"gae_app\"",
        "range": {
          "min": 0,
          "max": 1000
        }
      }
    }
  },
  "goal": 0.001,
  "calendarPeriod": "WEEK"
}
JSON
> {
>   "name": "projects/744005832574/services/prefix:lower_UPPER-01.23/serviceLevelObjectives/prefix:lower_UPPER-01.23",
>   "serviceLevelIndicator": {
>     "requestBased": {
>       "distributionCut": {
>         "distributionFilter": "metric.type=\"appengine.googleapis.com/http/server/response_latencies\" resource.type=\"gae_app\"",
>         "range": {
>           "max": 1000
>         }
>       }
>     }
>   },
>   "goal": 0.001,
>   "calendarPeriod": "WEEK"
> }

References

• Fix google_monitoring_slo import #11696
  • This PR addresses the issue of importing service in google_monitoring_slo, but it has been left for a year.
• It seems that the google_monitoring_service and google_monitoring_custom_service use the same API. However, google_monitoring_service does not have service_id validation.
  • mmv1/products/monitoring/Service.yaml (google_moniroting_custom_service)
  • mmv1/products/monitoring/GenericService.yaml (google_moniroting_service)

[github-actions]

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.