How to manage removing the first node pool but leave the second node pool in the array?

[prahaladramji]

eg. initial state.

node_pools = [
  {
    name         = "primary-node-pool"
    machine_type = "n1-standard-2"
  },
  {
    name         = "secondary-node-pool"
    machine_type = "n1-standard-2"
  },
]

later in the lifecycle, if we wanted to remove the primary-node-pool.

node_pools = [
  {
    name         = "secondary-node-pool"
    machine_type = "n1-standard-2"
  },
]

this basically tries to recreate a node and name it secondary-node-pool, this will fail cause that already exists.

      id:                                    "australia-southeast1/syd-01/primary-node-pool" => <computed> (forces new resource)
      autoscaling.#:                         "1" => "1"
      autoscaling.0.max_node_count:          "3" => "3"
      autoscaling.0.min_node_count:          "1" => "1"
      cluster:                               "ops-syd-01" => "ops-syd-01"
      initial_node_count:                    "1" => "1"
      instance_group_urls.#:                 "3" => <computed>
      management.#:                          "1" => "1"
      management.0.auto_repair:              "true" => "true"
      management.0.auto_upgrade:             "true" => "true"
      max_pods_per_node:                     "" => <computed>
      name:                                  "primary-node-pool" => "secondary-node-pool" (forces new resource)
      name_prefix:                           "" => <computed>
      node_config.#:                         "1" => "1"
      node_config.0.disk_size_gb:            "100" => "100"
      node_config.0.disk_type:               "pd-ssd" => "pd-ssd"
      node_config.0.guest_accelerator.#:     "0" => <computed>
      node_config.0.image_type:              "COS" => "COS"
      node_config.0.local_ssd_count:         "0" => <computed>
      node_config.0.machine_type:            "n1-standard-2" => "n1-standard-2"
      node_config.0.oauth_scopes.#:          "1" => "1"
      node_config.0.oauth_scopes.1733087937: "https://www.googleapis.com/auth/cloud-platform" => "https://www.googleapis.com/auth/cloud-platform"
      node_config.0.preemptible:             "false" => "false"
      node_config.0.service_account:         "default" => <computed>
      node_config.0.tags.#:                  "1" => "1"
      node_config.0.tags.0:                  "gke-01" => "gke-01"
      node_count:                            "1" => <computed>
      project:                               "project1" => "project1"
      region:                                "australia-southeast1" => "australia-southeast1"
      version:                               "1.11.7-gke.6" => <computed>
      zone:                                  "" => <computed>```

[perriea]

Hello @prahaladramji, thank you for your question. For the moment, the operation of Terraform does not allow to do what you wish to do ...

Are you trying to make terraform rm state <resource> and see the plan after that ?
Warning this action delete the node pool in the state. Don't do this in production !

[prahaladramji]

Hi @perriea, thanks for your reply.

No i'm not trying to do a terraform rm state <resource> basically when 2 node pools are defined terraform numbers the resource as

google_container_node_pool.pools[0]
google_container_node_pool.pools[1]

so the next time if the first definition is removed the newly defined nodepool shift's up in the array index and now terraform try's to make it google_container_node_pool.pools[0]

It's more a terrform problem, on how it handles lists of resources.
For now i'm using name_prefix instead of name with lifecycle block so it first creates an operational nodepool.

lifecycle {
    create_before_destroy = true
    ignore_changes        = ["initial_node_count"]
  }

Also as a workflow for maintenance, run terraform apply in this order

1. add a new pool.
2. drain old pool.
3. (after workloads have migrated to new pool) replace old pool with new configs.
4. drain the pool created in step 1.
5. delete the pool create in step 1.

Otherwise it would put the cluster in a broken state or cause interruptions to services currently running.