Terraform-provider-google: Enable dns_cache_config on exsting k8s version 1.15.x will still destroying the resource first

Created on 2 Apr 2020  ·  8Comments  ·  Source: hashicorp/terraform-provider-google


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

  • Terraform v0.12.20
  • Terraform Google Provider 3.15.0

Affected Resource(s)

  • google_container_cluster

Terraform Configuration Files

Before

resource "google_container_cluster" "gcc" {
    ...
    logging_service             = "logging.googleapis.com/kubernetes"
    monitoring_service          = "monitoring.googleapis.com/kubernetes"
    min_master_version          = "1.15.9-gke.26"
    addons_config {
    ...
    }
    ...
}

After

resource "google_container_cluster" "gcc" {
    ...
    logging_service             = "logging.googleapis.com/kubernetes"
    monitoring_service          = "monitoring.googleapis.com/kubernetes"
    min_master_version          = "1.15.9-gke.26"
    addons_config {
      ...
        dns_cache_config {
            enabled = true
        }
    }
    ...
}

Expected Behavior

Only recreate (destroy-create) cluster when the version is < 1.15.x.

Actual Behavior

Terraform destroy and re-create the google_container_cluster even its already on 1.15.x

Steps to Reproduce

  1. terraform apply

Important Factoids

If the google_container_node_pool already on 1.15.x., terraform apply detect no changes on the those resources. Unfortunately, the apply process destroy both resources but only re-create google_container_cluster leaving google_container_node_pool un-created.

bug

Most helpful comment

Now I can repro the issue. By adding dns_cache_config block in google_container_cluster and then tf apply, nodes are failed to be created. Below is the HCL I was using to repro the issue

resource "google_container_cluster" "primary" {
  provider = google-beta
  name     = "my-gke-cluster"
  location = "us-central1"
  min_master_version  = "1.15.9-gke.26"
  remove_default_node_pool = true
  initial_node_count  = 1
  master_auth {
    username = ""
    password = ""
    client_certificate_config {
      issue_client_certificate = false
    }
  }
    addons_config {
        http_load_balancing {
                disabled = true
        }
#       dns_cache_config {
#           enabled = true
#        }
    }
}
resource "google_container_node_pool" "primary_preemptible_nodes" {
 provider = google-beta
name       = "my-node-pool"
  location   = "us-central1"
  cluster    = google_container_cluster.primary.name
  node_count = 3
  node_config {
    machine_type = "n1-standard-1"
    metadata = {
      disable-legacy-endpoints = "true"
    }
    oauth_scopes = [
      "https://www.googleapis.com/auth/logging.write",
      "https://www.googleapis.com/auth/monitoring",
    ]
  }
}

All 8 comments

@antrusd I'd like to repro your issue. How did you specify master_version? Do you have more complete HCL that I can use to repro your issue?

My bad, master_version was taken from the output of terraform plan, actually it's min_master_version. Original report edited. What I'm doing is basically update an existing 1.15.x cluster by add dns_cache_config.

OTOH,I have been trying to enable NodeLocal DNSCache by gcloud command on separate cluster (also on an existing 1.15.x), it does not destroy the cluster. So I believe the API have non-disruptive mechanism.

Seeing this issue too where trying to enable dns_cache_config on a cluster with master + worker nodes at 1.15.9-gke.24 results in an attempt to destroy the cluster (I'm using Pulumi which actually rejects this update with the error panic: fatal: An assertion has failed: Expected diff to not require deletion or replacement during Update of urn:pulumi:<pulumi-stack>::<pulumi-project>::gcp:container/cluster:Cluster::<cluster-name>).

The expected behaviour should be that only the nodes are recreated here.

Now I can repro the issue. By adding dns_cache_config block in google_container_cluster and then tf apply, nodes are failed to be created. Below is the HCL I was using to repro the issue

resource "google_container_cluster" "primary" {
  provider = google-beta
  name     = "my-gke-cluster"
  location = "us-central1"
  min_master_version  = "1.15.9-gke.26"
  remove_default_node_pool = true
  initial_node_count  = 1
  master_auth {
    username = ""
    password = ""
    client_certificate_config {
      issue_client_certificate = false
    }
  }
    addons_config {
        http_load_balancing {
                disabled = true
        }
#       dns_cache_config {
#           enabled = true
#        }
    }
}
resource "google_container_node_pool" "primary_preemptible_nodes" {
 provider = google-beta
name       = "my-node-pool"
  location   = "us-central1"
  cluster    = google_container_cluster.primary.name
  node_count = 3
  node_config {
    machine_type = "n1-standard-1"
    metadata = {
      disable-legacy-endpoints = "true"
    }
    oauth_scopes = [
      "https://www.googleapis.com/auth/logging.write",
      "https://www.googleapis.com/auth/monitoring",
    ]
  }
}

The node pool isn't being recreated due to the issue here: https://github.com/hashicorp/terraform-plugin-sdk/issues/122.
However, it looks as though dns_cache_config shouldn't be ForceNew, which will solve this particular issue. We may run into the same issue with the node pool if other ForceNew fields are updated though, so I wanted to make that note here for future reference.

Do we know what release this will make it in? I've done some digging and it was merged into master before the last release was cut but didn't make it into the release.

Confused on how the release process works in this waterfall of automation.

Hi @jmymy! Sorry for the confusion, it will be released in the 3.18.0 release. Thanks!

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!

Was this page helpful?
0 / 5 - 0 ratings