terraform plan always finds a disk device_name diff

[dghubble]

Existing google_compute_instance_template resources recently started being recreated on every run of terraform apply. This is quite dangerous in its own right. Even performing the apply, plan still shows the same desired diff.

Terraform Version

v0.10.4

Affected Resource(s)

• google_compute_instance_template

Terraform Configuration Files

resource "google_compute_instance_template" "controller" {
  ...
  disk {
    auto_delete  = true
    boot         = true
    source_image = "${var.os_image}"
    disk_size_gb = "${var.disk_size}"
  }
...

Example resource affected: https://github.com/poseidon/typhoon/blob/a5290dac3284ee4f1101e55a925dfd90c1e09809/google-cloud/container-linux/kubernetes/controllers/controllers.tf#L39

Actual Behavior

$ terraform plan
...
disk.0.device_name:                         "persistent-disk-0" => "" (forces new resource)

Running terraform apply (just for debugging) and then re-running terraform plan shows the same suggested diff.

Expected Behavior

terraform plan should not show a diff.

References

• r/compute_instance_template: Make disk.device_name computed #566 cc @radeksimko
• Re-applying breaks existing GCE clusters poseidon/typhoon#34

[dgolja]

We have the same issue. Basically rerunning the plan tries to recreate all the IT.

[dghubble]

I see this behavior even using old plugins, which is surprising at first. But looking through old versions, the device_name field is not new, its been there all along, likely defaulting to "". I suspect the actual API has changed recently to start populating that value (seems innocent right, going from "" to a default value) and terraform is diligently trying to "fix" all existing instance groups.

I managed to wipe gce clusters because of this (we happen to prepare for this and failed over to another cloud), not noticing that suddenly a new change was proposed that would delete instance groups.

The change in #566 looks like it may be a solution, to address the API change, but its not available in a release that gets picked up by terraform init. Maybe a local build can be used.

[dgolja]

Hmmm in our case only the IT get recreated and IG gets only updates, so this shouldn't be a destructive action. Despite that it's annoying because of how GCP deals with old IT and the whole rolling update dance.

[dghubble]

Yeah, only the instance_template resource itself is destroyed and recreated. The rest depends on usage, in my case the instance group is updated and each instance is replaced, which wasn't expected.

Workaround to avoid recreating the template is to explicitly set the device_name to "persistent-disk-0".

This seems to be an actual API change and this plugin has already made the change to start computing the name, which is about all that can be done in this source code.

[dghubble]

I'm content to close this. Its unfortunate. But the plugin already seems to have made the change that will be needed.

[dgolja]

What if you don't use terraform-google-kubernetes ? Could you leave it open until at least they release the #566 ?

[dghubble]

I suppose it'd be nice if someone could clarify the "breaking API change" mentioned in #566 and the above analysis or maybe nudge along a release.

I don't think a code change or fix to this project is needed so feel free to close again.

[paddycarver]

Essentially what happened (as far as I can tell) is that the API updated to return a default device_name when one is not set. Previously, we were expecting whatever we set to get returned, including if we set nothing, because that was the old behavior. #566 fixed this issue within hours of the API change occurring, but we needed to prepare the release, which unfortunately takes some time.

We've just released 1.1.0, which should solve this problem. I'm going to close this issue, as the fix is released. If you've updated to 1.1.0 and are still having trouble, please don't hesitate to open a new issue or reply here.

[dghubble]

Thanks!

[dgolja]

thank you for the quick resolution.

[ghost]

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 👉 hashibot-feedback@hashicorp.com. Thanks!