Cannot Control Private Service Access Range Name within net-vpc module

[jamesdalf]

Since version 31.0.0, the way psa is configured within the net-vpc module was changed. It now allows for multiple psa configurations for different service producers. However, introducing this update changed how the the PSA IP ranges are named. It appends the service producer to the range.

# module.spoke-vpcs["fat"].google_compute_global_address.psa_ranges["servicenetworking-googleapis-com-psa"] must be replaced
  # (moved from module.spoke-vpcs["fat"].google_compute_global_address.psa_ranges["psa"])
-/+ resource "google_compute_global_address" "psa_ranges" {
      ~ creation_timestamp = "2024-08-07T04:15:40.256-07:00" -> (known after apply)
      ~ effective_labels   = {} -> (known after apply)
      ~ id                 = "..." -> (known after apply)
      ~ label_fingerprint  = "..." -> (known after apply)
      - labels             = {} -> null
      ~ name               = "psa" -> "servicenetworking-googleapis-com-psa" # forces replacement
      ~ network            = "..."
      ~ self_link          = "..." -> (known after apply)
      ~ terraform_labels   = {} -> (known after apply)
        # (5 unchanged attributes hidden)
    }

As a PSA range cannot be renamed, it must be replaced. There is not easy way (without resource migrations) to use the latest module if you have existing PSA ranges in use.

A PSA range can be assigned to multiple service producers. Therefore the name of the range shouldn't be based on the producer. In the image below we can see the range james-test is assigned to two different service producers.

Desired outcome would be to decouple the range name from the service producer. Or to support some backwards compatibility to ensure ranges aren't re-created

[juliocc]

While we come up with a proper fix, as a quick workaround you can use a moved block to let terraform know about the new name without having to recreate anything.

[jamesdalf]

I did try the moved block. Actually the example I provided is performing the move. The terraform resource re-name is easily handled with a moved block. However, the GCP resource re-name means it will be re-created. The issue is on the GCP resource name not the terraform resource. A PSA range is just one of those resources that can't be re-named it seems

[juliocc]

You're absolutely right.

I'm meeting with @sruffilli today and we'll try to come up with a solution for this.

[ludoo]

A sensible alternative (I think I was the one making the change in #2218) is to add an optional field to the variable definition:

variable "psa_configs" {
  description = "The Private Service Access configuration."
  type = list(object({
    deletion_policy  = optional(string, null)
    ranges           = map(string)
    export_routes    = optional(bool, false)
    import_routes    = optional(bool, false)
    peered_domains   = optional(list(string), [])
    service_producer = optional(string, "servicenetworking.googleapis.com")
    use_legacy_names = optional(bool, false)
  }))

and then avoid interpolating the service producer if that is true:

_psa_configs_ranges = flatten([
    for config in local.psa_configs : [
      for k, v in config.ranges : {
        key   = v.use_legacy_names ? k : "${config.key}-${k}"
        value = v
      }
    ]
  ])

[ludoo]

Or even better, we only interpolate if service name is != "servicenetworking.googleapis.com" (which has the drawback of breaking compatibility for current users).

[jamesdalf]

Thanks for looking into this so quickly!
@ludoo, I like the idea of the first one since it wouldn't break compatibility for any users once they know how to add the extra property. This gives the control we would need and still allows for a way forward for new ranges too.

I like the second idea as well but then others might run into the same issue we have.

[ludoo]

s might run into the same issue we have.

We implemented a variation of the first one, where you can set arbitrary prefixes or skip them entirely. The second example in the module's README should do what you need.

Thanks a lot for raising this issue and being open to discussion. :)

[jamesdalf]

Thanks as well for being so fast to respond! I will try out the new version

[jamesdalf]

It works perfectly! Again thanks for the support. We can close this issue :)