FYI before you start- I've been debugging this for a while and know why the problem is occurring, just not how to fix it without breaking other things :)
Happy to give debug logs if necessary, but I don't suspect there will be anything useful in them besides what I'm telling you here (given that I've spent all day staring at them myself).
v0.11.7
Also repros with v0.11.8-dev (build from source)
resource "google_container_cluster" "primary" {
name = "is-1566"
network = "test-network"
subnetwork = "test-subnet"
node_pool = {
name = "default-pool"
}
lifecycle = {
ignore_changes = ["node_pool"]
}
}
resource "google_container_node_pool" "np" {
name = "second-pool"
cluster = "${google_container_cluster.primary.name}"
node_count = 1
}
No diff because there's a DiffSuppressFunc on network and subnetwork
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
~ update in-place
Terraform will perform the following actions:
~ google_container_cluster.primary
network: "projects/graphite-test-danahoffman-tf/global/networks/test-network" => "test-network"
subnetwork: "projects/graphite-test-danahoffman-tf/regions/us-central1/subnetworks/test-subnet" => "test-subnet"
terraform initterraform applyterraform planHere's what's happening:
Terraform enters into Eval, and calls diff on the provider:
https://github.com/hashicorp/terraform/blob/fce30c14f051bed407216117cd36394a8f78c401/terraform/eval_diff.go#L116-L120
which then calls diff on each of the attributes:
https://github.com/hashicorp/terraform/blob/fce30c14f051bed407216117cd36394a8f78c401/helper/schema/schema.go#L423-L428
In this particular example, the diffs for network and subnetwork are suppressed (as expected), and node_pool.# shows a diff because the cluster has two node pools but only one is in the config.
Because node_pool is a ForceNew field, it sets RequiresNew on the diff, and because it does that, we hit this block where it empties the state and computes a new diff:
https://github.com/hashicorp/terraform/blob/fce30c14f051bed407216117cd36394a8f78c401/helper/schema/schema.go#L457-L476
Now, because the state is empty, our DiffSuppressFunc returns false for network and subnetwork because it's comparing our config against the empty string.
Then, we return from our initial Diff() call back into Eval(), and filter out ignored attributes:
https://github.com/hashicorp/terraform/blob/fce30c14f051bed407216117cd36394a8f78c401/terraform/eval_diff.go#L164-L167
This removes the diff on node_pool, but leaves in the diff for network and subnetwork, thus producing the plan output seen above.
https://github.com/terraform-providers/terraform-provider-google/issues/988
https://github.com/terraform-providers/terraform-provider-google/issues/1566 (where this repro comes from)
https://github.com/terraform-providers/terraform-provider-google/issues/1610
Hi @danawillow,
Thanks for the excellent detective work here!
We're going to be making some significant changes to the helper/schema package soon, which will provide us with a chance to better handle the issue. As shown here, because it's based on the interaction between core and the provider this may not be something that can be fixed for existing terraform releases, but should be something covered in 0.12.
Hi!
any updates on this issue?
Also, thanks for the investigation!
This is very very annoying. I hope this can be addressed soon.... sigh
This is fixed in master, with a test to verify added in the commit linked above.
was this actually fixed? im still seeing the behavior in google_container_cluster in tf v0.11.10
I have to do this in order to prevent tf from seeing changes every time:
network = "projects/${var.project}/global/networks/${var.network}"
subnetwork = "projects/${var.project}/regions/${var.region}/subnetworks/${var.subnet}"
It should be part of upcoming terraform v0.12, it doesn’t seem to be in the v0.11 branch.
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.
Most helpful comment
This is fixed in master, with a test to verify added in the commit linked above.