data "google_project_service": support using future project ids or optional project argument

[lemoo5sg]

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

For some internal use cases, we need to use the google_project_service data source before creating the scanned project by specifying a foreseen project id.

Example:

data "google_project_service" “service" {
  project = “future_project_id”
  service = "x.googleapis.com"
}

When executing a plan, the respective plan fails with the following error:

“Error: Error when reading or editing Project Service future_project_id/x.googleapis.com: googleapi: Error 400: Request contains an invalid argument., badRequest

  with data.google_project_service.service,
  on main.tf line xxx, in data "google_project_service" "service":

Could you please update the data source so that for this limit case, the plan does not fail and returns an empty service output as it currently does when the project id is ok and the service is not enabled.

If this is not accepted, an alternative would be using the google_project_service data source with our provider project by setting the project argument to null when needed.

Example:

data "google_project_service" “service" {
  project = var.project_id == “unknown”  ? null : var.project_id
  service = "x.googleapis.com"
}

According to the documentation [1] the “project” argument is described as optional and the provider project is used.

However, when executing a plan, the respective plan fails with the following error:

Error constructing id: project: required field is not set
  with data.google_project_service.service,
  on main.tf line xxx, in data "google_project_service" "service":

Still if the above change is not accepted, could you please make the project argument optional as mentioned in the documentation [1]?

New or Affected Resource(s)

• data "google_project_service"

Potential Terraform Configuration

Preferred:

data "google_project_service" “service" {
  project = “future_project_id”
  service = "x.googleapis.com"
}

Alternative:

data "google_project_service" “service" {
  project = var.project_id == “unknown”  ? null : var.project_id
  service = "x.googleapis.com"
}

References

Reference documentation:

• [1] https://registry.terraform.io/providers/hashicorp/google/latest/docs/data-sources/google_project_service

[rileykarson]

@lemoo5sg can you elaborate on what your use case is? In general, we'd expect datasources to refer to resources that already exist.

[lemoo5sg]

@rileykarson I'm with you usualy we want to refer to existing resources. In our case we have a module that could be used in several contexts, sometimes the project id will refer to a project that is not created yet but we already know the project id, the proejct might be created later by another pipeline for example. When the project id is provided but no project is there, we would like the google_project_service data source to return peacefully the information without a crash of the terraform run so that we can check the result and act accordingly.

[rileykarson]

Thanks! This would go against other changes we're making in the provider, where we want to ensure that all datasources return explicit errors: #12873

Functionality like this would be possible to expose through Terraform Core, where it could ignore errors from the provider based on a lifecycle directive or other rule.

[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.