Create secondary_ip_range without compute_subnetwork

[eraac]

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

Add a new resource allowing to manage the secondary ip ranges in a subnetwork without the resource google_compute_subnetwork.

If you've an VPC with auto subnetworks on, you don't manage the subnetwork (meaning you don't have the resource in your terraform).

New or Affected Resource(s)

• google_compute_subnetwork_secondary_ip_ranges

Potential Terraform Configuration

resource "google_compute_subnetwork_secondary_ip_range" "secondary_range" {
  subnetwork = "..."
  name = "..."
  cidr_range = ".../xx"
}

Workaround

resource "null_resource" "secondary_ip_range" {
  provisioner "local-exec" {
    command = format(
      "gcloud --project %s compute networks subnets update %s --region %s --add-secondary-ranges %s=%s,%s=%s",
    )
  }

  provisioner "local-exec" {
    when = destroy

    command = format(
      "gcloud --project %s compute networks subnets update %s --region %s --remove-secondary-ranges %s,%s",
    )
  }
}

[eraac]

Just find my own issue after facing the same problem again 😅

[chrisghill]

Running into this issue when trying to create a GKE module. The secondary ranges are specifically for the GKE pods and services, so it would be nice to be able to provision them and destroy them alongside the GKE cluster itself.

It seems the situation is a bit similar to the AWS route_table/route or security_group/security_group_rule resources. The AWS provider solves it by allowing you to provision the route_table resource, then separately you can provision individual routes within the route table. That same pattern could be used here, where the google_compute_subnetwork is provisioned as part of a network module, and the suggested google_compute_subnetwork_secondary_ip_range could be provisioned alongside the resource that uses it (google_container_cluster for example).

[guhcampos]

A new use case: I have a terraform config which must be applied in two different environments - say staging and production and for some reason (preexisting config, for example) the address ranges are not exactly the same in a subnet. Staging might have a different number of secondary ranges than Production, or in different order.

This makes it impossible to use an already bad strategy such as:

resource "google_container_cluster" "potato" {
  ...

  ip_allocation_policy {
    cluster_secondary_range_name  = data.google_compute_subnetwork.my_subnet.secondary_ip_range.0.range_name
    services_secondary_range_name = data.google_compute_subnetwork.my_subnet.secondary_ip_range.1.range_name  
  }
}

Ideally, I should be able to query the ranges individually, so in different environments I could do:

data "google_compute_subnetwork_secondary_ip_range" "pod_range" {
  network = ...
  subnet = ...
  cidr = "10.0.0.0/24" 
  # OR
  name = "pod-range-1234"
}
resource "google_container_cluster" "potato" {
  ...

  ip_allocation_policy {
    cluster_secondary_range_name  = data.google_compute_subnetwork_secondary_ip_range.pod_range.name
  }
}