@queeno in below config, do you intend to set provider?

resource "google_service_account" "test" {
  provider = google.test_project.      <------ project or provider?
  display_name = "test-service-account"
  account_id = "test-service-account"
}

@edwardmedia I intend to set the provider
This example might not make much sense, but in my use case, the google_service_account resource is part of a separate module using the "test_project" as default provider.

We may want to guard this on a setting- with the current 5.0.0 behaviour as strict mode and a mode without errors as a relaxed mode. Which we default to is a bit of an open question given 5.0.0 is strict, so 5.X.0 could preserve that as the default or switch to relaxed mode. I'll gather some opinions from folks.

It appears that not all resources enforce this 'strict' mode. I've noticed that, out of 706 resources, only 312 seem to include the provider check. A list of non-supported resources is available here

I only realised because this check was introduced in 5.0.0 on the google_service_account resource. For example, the google_storage_bucket resource doesn't support this check.

I'd argue that, would we want to enforce a 'strict' mode on plan, we should make sure that the check is run on all resources.

Furthermore, I'm also wondering what the benefit of a 'strict' mode would be.

• Do we want to avoid resources being provisioned in an unexpected project? - should the Google provider's project parameter be compulsory rather than optional?
• Do we want to avoid the terraform apply failing because of unset project? - can we check whether the provider's project is set, but to be generated at apply time vs totally unset?

To explain part of this as the one who implemented the change: the resources without the defaultprovider/region/zone displays were those that do not support using system default values on the project field or for which project was not a part of the schema. There was some false positives in making the list of resources to not apply including it to (google_storage_bucket being one of the only I can see going down the list of handwritten resources without it included), but this change to support displaying default provider values at plan-time is intended as universally reaching (within the mentioned conditions).

Do we want to avoid resources being provisioned in an unexpected project?
Do we want to avoid the terraform apply failing because of unset project?

Yes to both! The change was made to help make plans more explicit about resources were going, and to improve the validation of users' configurations at plan time.

can we check whether the provider's project is set, but to be generated at apply time vs totally unset?

I believe we can reliably check this at the resource level, but not at the provider level where both unknown and unset are considered the same value. That's where guarding behind a flag could help, unless we can gather more information. For the majority of configurations where provider default projects are known we can move project validation up to plan time, and users who are using providers whose attributes are determined mid-apply could ignore that validation.

We didn't capture that flow correctly- I knew it was possible, having worked with the Kubernetes provider and GKE resources within a single config, but didn't think it would be relevant for this change.

We'll do some investigation and see if we can find a way to detect unknown values on the provider, and investigate a flag or alternative if we can't.

I only realised because this check was introduced in 5.0.0 on the google_service_account resource. For example, the google_storage_bucket resource doesn't support this check.

google_storage_bucket's project field is optional, unlike other resources' which is optional at the resource level but mandatory through either the resource or project. google_storage_bucket do need a project at creation, but can be imported without one as their Get method is just based on the globally unique bucket name.

Organization-level resources (google_access_context_manager_*, google_apigee_* etc) don't use any provider defaults, as they're generally global and organizations are above projects in the resource hierarchy.

There are similar complications throughout other resources that mean this check can't be universal. That's not a guarantee that we applied it to every possible resource, but I don't think we'd reliably be able to promise literally every resource behaved as expected (particularly because backfilling resources we missed will need to happen in major versions).

I am getting all kinds of pain when I do something similar. but I do this:

resource "google_service_account" "cluster" { project = google_project.main.id account_id = "sa-gke-${var.application_name}-${var.environment_name}-${random_string.project_id.result}" display_name = "sa-gke-${var.application_name}-${var.environment_name}-${random_string.project_id.result}" }

I also create the project in my root module an I want to create this service account within the context of that project that is created within the current module (hence the reference to the project resource.

I get this very strange error:

<p><b>404.</b> <ins>That’s an error.</ins> │ <p>The requested URL <code>/v1/projects/projects/MY_PROJECT_ID/serviceAccounts?alt=json&amp;prettyPrint=false</code> was not found on this server. <ins>That’s all we know.</ins>

Seems like the project attribute of the the 'google_service_account' resource type is not building the correct path to the API it's calling. Not sure why.

@rileykarson @NickElliot I'm seeing the same issues after upgrading to v5, using basically something like the below. What's the proper way to provision projects like this, as this doesn't seem to be "the way"?

resource "random_integer" "main" {
  min = 1
  max = 99999
}

locals {
  project_slug = "test"
  project_id = "${local.project_slug}-${random_integer.main.id}"
}

resource "google_project" "main" {
  project_id          = local.project_id
}

resource "google_project_service" "serviceusage-api" {
  service            = "serviceusage.googleapis.com"
  project            = local.project_id
  disable_on_destroy = false

  depends_on = [
    google_project.main
  ]
}

provider "google" {
  project                                       = local.project_id
}

https://cloud.google.com/docs/terraform/best-practices-for-terraform#randomize