Inconsistent plan with `create_environment_v2` and `composer_net`

[Sarapuce]

TL;DR

With 2 cloud composer deployed in shared network like here, planning one composer make the plan of the other one inconsistent.

Deploying 2 composers can be usefull if you have a prod and a dev project

Each time you apply the example, it works fine for the concerned layer, but in the otehr one, you will have the following error :
module.composer_env.google_project_iam_member.composer_agent_service_account[0] must be replaced

Expected behavior

Once applied, the plan should be empty.

Observed behavior

Each time I apply, I have this resource which want to be replaced

  # module.composer_env.google_project_iam_member.composer_agent_service_account[0] must be replaced
-/+ resource "google_project_iam_member" "composer_agent_service_account" {
      ~ etag    = "a8Ge3sGGfd6=" -> (known after apply)
      ~ id      = "project/roles/composer.ServiceAgentV2Ext/serviceAccount:service-xxx@cloudcomposer-accounts.iam.gserviceaccount.com" -> (known after apply)
      ~ member  = "serviceAccount:service-xxxx@cloudcomposer-accounts.iam.gserviceaccount.com" # forces replacement -> (known after apply) # forces replacement
        # (2 unchanged attributes hidden)
    }

Terraform Configuration

module "composer_env" {
  depends_on = [
    module.composer_net
  ]
  source                           = "git@github.com:terraform-google-modules/terraform-google-composer.git//modules/create_environment_v2"
  project_id                       = "xxx"
  network_project_id               = "xxx"
  composer_env_name                = "composer"
  composer_service_account         = module.composer_net.composer_sa_email
  kms_key_name                     = "projects/xxx/locations/europe-west1/keyRings/xxx/cryptoKeys/xxx"
  region                           = "europe-west1"
  network                          = "projects/xxx/global/networks/xxx"
  subnetwork                       = "projects/xxx/regions/europe-west1/subnetworks/xxx"
  pod_ip_allocation_range_name     = "composer-pod-main"
  service_ip_allocation_range_name = "composer-service-main"
  grant_sa_agent_permission        = true
  use_private_environment          = true
  enable_private_endpoint          = true
  environment_size                 = "ENVIRONMENT_SIZE_SMALL"
  resilience_mode                  = "STANDARD"
  storage_bucket                   = google_storage_bucket.this.name
  scheduler = {
    cpu        = 2
    memory_gb  = 1
    storage_gb = 1.875
    count      = 1
  }
  web_server = {
    cpu        = 1
    memory_gb  = 2
    storage_gb = 10
  }
  worker = {
    cpu        = 1
    memory_gb  = 2
    storage_gb = 1
    min_count  = 2
    max_count  = 6
  }
}

Terraform Version

Terraform v1.6.3
on linux_amd64
+ provider registry.terraform.io/hashicorp/google v5.13.0
+ provider registry.terraform.io/hashicorp/google-beta v5.13.0

Additional information

This is perhaps due to a local being used to calculate the service account name. The replacement is caused by this line : ~ member = "serviceAccount:service-xxxx@cloudcomposer-accounts.iam.gserviceaccount.com" # forces replacement -> (known after apply) # forces replacement So perhaps by changing this line in the code source, it should work

iam.tf :
member = format("serviceAccount:%s", local.cloud_composer_sa) into member = format("serviceAccount:service-${google_project.project.number}@cloudcomposer-accounts.iam.gserviceaccount.com", local.cloud_composer_sa)

After trying to change that, nothing changed

[imrannayer]

@Sarapuce if you are deploying 2 composer instances in same shared VPC network then it will be better to set grant_sa_agent_permission to false in all but one module call. This should fix the issue.

[Sarapuce]

Yep it works ! Thanks !