```ip_allocation_policy``` configuration in example seems incorrect

[moshem-pangea]

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 an 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 an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to hashibot, a community member has claimed the issue already.

Terraform Version

N/A

Affected Resource(s)

google_compute_subnetwork

Terraform Configuration Files

N/A

Debug Output

N/A

Panic Output

N/A

Expected Behavior

The example provided on the official guide for VPC-native clusters seems incorrect in the ip_allocation_policy section:
cluster_secondary_range_name, which according to the documentation refers to the pod IP addresses ranges, appears in the example pointing to "services-range", while services_secondary_range_name which - as its name suggests - refers to the services IP addresses range, points in the provided example to google_compute_subnetwork.custom.secondary_ip_range.1.range_name, which is the pod ranges. It should be the opposite. The expected look of the ip_allocation_policy block in the example should be:

  ip_allocation_policy {
    cluster_secondary_range_name  = "pod-range"
    services_secondary_range_name = google_compute_subnetwork.custom.secondary_ip_range.0.range_name
  }

Actual Behavior

Current example of ip_allocation_policy in VPC-native cluster documentation looks like:

  ip_allocation_policy {
    cluster_secondary_range_name  = "services-range"
    services_secondary_range_name = google_compute_subnetwork.custom.secondary_ip_range.1.range_name
  }

Steps to Reproduce

N/A

Important Factoids

References

[edwardmedia]

@moshem-pangea aren't both names relative? What if we use below instead? Or vice versa? Make any difference?

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

[moshem-pangea]

@edwardmedia: My point is, that the google_compute_subnetwork block in the example is defined with the services range before the pods (- cluster) range. As a result, I assume that the services range should be referred with the identifier 0, and the cluster range with the identifier 1.

It doesn't matter if it'll be referred using google_compute_subnetwork.custom.secondary_ip_range.{number}.range_name or using the explicit name ("services-range" and "pod-ranges"). What matters is, that the services range and pods range will point to the correct subnetwork ranges.

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.