apply cannot succeed on first run when a service account and registry access are both requested

[tpdownes]

This issue is similar to several recent issues. I believe commit 83eae98 by @rux616 in #815 has created a situation in which terraform apply cannot possibly succeed on the first run.

If one intends to create a GKE cluster with both create_service_account and grant_registry_access enabled, it requires a local variable to already exist.

resource "google_project_iam_member" "cluster_service_account-artifact-registry" {
  for_each = var.create_service_account && var.grant_registry_access ? toset(local.registry_projects_list) : []
  project  = each.key
  role     = "roles/artifactregistry.reader"
  member   = "serviceAccount:${google_service_account.cluster_service_account[0].email}"
}

Removing the local variable and providing a dummy set allows a plan to succeed (although it would probably bork on a real apply). e.g.

  for_each = var.create_service_account && var.grant_registry_access ? toset(["hello"]) : []

I should not have to do a partial apply to use terraform.

To avoid the suggestion @morgante has made in other issues, there is no state to remove.

$ terraform state list
No state file was found!

State management commands require a state file. Run this command
in a directory where Terraform has been run or use the -state flag
to point the command to a specific state location.

[morgante]

Can you share your full Terraform config please? We have tests which should catch this if it's not possible, so I think the create_service_account part is a red herring.

[tpdownes]

Downgrading to 13.0.0 is sufficient to workaround this issue but it should be resolved in a future release. It becomes an issue in 13.1.0.

[tpdownes]

Filed comments past one another but the logic of var.create_service_account && var.grant_registry_access was apparent to me. I was A-OK until I set both variables.

[tpdownes]

A side conversation with @morgante identifies this as a consequence of creating a project in the same state file as the code in question. If I separate that out, the issue resolves and is in line with best practices.