Unable to specify pod_ipv4_range_names?

[cwh-hcl]

TL;DR

Doing a terraform plan on my imported cluster shows it wants to remove my additional_ip_ranges_config block. My existing cluster has pod_ipv4_range_names defined. See below screen cap of terraform plan output.

I do not see any way that the module accepts input to control the pod_ipv4_range_names. This setting is supported by the google_container_cluster resource: https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/container_cluster#pod_ipv4_range_names-1

Please let me know any additional information required.

Expected behavior

Should be able to specify pod_ipv4_range_names

Observed behavior

Terraform wants to remove the additional_ip_ranges_config block

Terraform Configuration

not applicable

Terraform Version

Terraform v1.13.0
on linux_amd64
+ provider registry.terraform.io/hashicorp/google v7.1.1
+ provider registry.terraform.io/hashicorp/kubernetes v2.38.0
+ provider registry.terraform.io/hashicorp/random v3.7.2

Your version of Terraform is out of date! The latest version
is 1.13.1. You can update by downloading from https://developer.hashicorp.com/terraform/install

Terraform Provider Versions

Providers required by configuration:
.
├── provider[registry.terraform.io/hashicorp/google] >= 6.28.0
└── module.kubernetes-engine
    ├── provider[registry.terraform.io/hashicorp/kubernetes] ~> 2.10
    ├── provider[registry.terraform.io/hashicorp/random] >= 2.1.0
    └── provider[registry.terraform.io/hashicorp/google] >= 6.42.0, < 8.0.0

Providers required by state:

    provider[registry.terraform.io/hashicorp/google]

Additional information

Interestingly when I use version 36.1.0 of the GKE module and version 6.28.0 of the hashicorp/google provider the terraform plan command does NOT try to remove the additional_ip_ranges_config block

[DrFaust92]

I think i made a copy paste mistake here, checking

[cwh-hcl]

I am still having an issue in v40.0.0. I think it is because the module is using a list for the variable additional_ip_ranges_config but it is actually not a list expected by the google_container_cluster resource

terraform-google-kubernetes-engine/variables.tf

Lines 158 to 162 in a021e55

	variable "additional_ip_ranges_config" {
	type = list(object({ subnetwork = string, pod_ipv4_range_names = list(string) }))
	description = "the configuration for individual additional subnetworks attached to the cluster"
	default = []
	}

Here's a link to the resource showing it does not expect a list for this block as well: https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/container_cluster#nested_additional_ip_ranges_config

The error I received:
When I tried to specify this variable as a list as the currently implementation of the module expects:

additional_ip_ranges_config = [{
	subnetwork = "iso-integration-add-0",
	pod_ipv4_range_names = ["integration-new-pods-range"],
}]

I received this error:

Error: Unsupported attribute

  on ../../../modules/terraform-google-kubernetes-engine-40.0.0/cluster.tf line 417, in resource "google_container_cluster" "primary":
 417: subnetwork = var.additional_ip_ranges_config.subnetwork
    ├────────────────
    │ var.additional_ip_ranges_config is a list of objects with 1 element

Can't access attributes on a list of objects. Did you mean to access the attribute "subnetwork" for a specific element of the list, or across all elements of the list?

───────────────────────────────────────────────────────────────────────────────

Error: Unsupported attribute

@DrFaust92 @

  on ../../../modules/terraform-google-kubernetes-engine-40.0.0/cluster.tf line 418, in resource "google_container_cluster" "primary":
 418: pod_ipv4_range_names = var.additional_ip_ranges_config.pod_ipv4_range_names
    ├────────────────
    │ var.additional_ip_ranges_config is a list of objects with 1 element

Can't access attributes on a list of objects. Did you mean to access the attribute "pod_ipv4_range_names" for a specific element of the list, or across all elements of the list?

@DrFaust92 @apeabody can either of you re-open this issue on my behalf? Or would you prefer me to make a new issue to track?

[apeabody]

Thanks for reporting @cwh-hcl - I belive this is being worked on in: #2458