Terraform forces to recreate instance after gcloud compute instances move

[ghost]

This issue was originally opened by @Cib0rg as hashicorp/terraform#20463. It was migrated here as a result of the provider split. The original body of the issue is below.

---

Hello.

We use terraform. We create large infrastructure with it and now trying to scale it down. Earlier we put instances in three zones and now we need only two zones. So I try to move instances between zones with gcloud compute instance move and terraform always try to recreate instance. Even after manual correction of tfstate i see following:

-/+ google_compute_instance.us1101apn[2] (new resource required)
id: "us1101apn003" => (forces new resource)
allow_stopping_for_update: "true" => "true"
boot_disk.#: "1" => "1"
boot_disk.0.auto_delete: "true" => "true"
boot_disk.0.device_name: "persistent-disk-0" =>
boot_disk.0.disk_encryption_key_sha256: "" =>
boot_disk.0.initialize_params.#: "1" => "1"
boot_disk.0.initialize_params.0.image: "" => "project/some-image" (forces new resource)

But when I try to take a look into state I see following:

terraform state show google_compute_instance.us1101apn[2]
id = us1101apn003
allow_stopping_for_update = true
attached_disk.# = 0
boot_disk.# = 1
boot_disk.0.auto_delete = true
boot_disk.0.device_name = persistent-disk-0
boot_disk.0.disk_encryption_key_raw =
boot_disk.0.disk_encryption_key_sha256 =
boot_disk.0.initialize_params.# = 1
boot_disk.0.initialize_params.0.image = https://www.googleapis.com/compute/v1/projects/project/global/images/some-image

Terraform Version

Terraform v0.11.11

• provider.google v1.20.0

Expected Behavior

Terraform should correctly pick up data from it state

Actual Behavior

Terraform don't pick up disk image data

Steps to Reproduce

1. Create some instance
2. gcloud compute instance move it to another zone
3. (optional) Correct zones in tfstate
4. terraform plan

Additional Context

References

[nat-henderson]

We don't support out-of-band management and reconciliation in terraform - the tool isn't designed to be used that way. The only approach that is guaranteed to work is to change your terraform config to match your desired new state, and run terraform apply - allowing it to change your infrastructure, rather than changing it yourself and trying to reconcile Terraform with the new state.

In this case, the reason that it is not possible is that running gcloud compute instances move changes the API representation of the object so that it cannot be reconciled with the local state anymore - this doesn't seem to be solvable. Even a state rm and import won't fix it - the API representation is not usable with Terraform any longer, and can't be reconciled except by a delete/recreate.

We'll try to modify our provider to be more forgiving in these cases, and I'll keep looking for alternate solutions, but in the meantime you should probably do the delete/recreate if at all possible.

[nat-henderson]

Aha! What happens when you move the resource is:

• the original instance is stopped
• the disk is copied between regions
• a new instance is spun up in the new region with the same parameters and disk

Consequently, it is no longer accurate to say that the instance was initialized from projects/some_image - instead, it has been initialized from the new copy of the disk in the new region! You can avoid a delete/recreate by changing your config to reflect that! Remove the initialize_params block, and add a source attribute which points to the image's disk. You can get the image's disk's self_link from the "equivalent REST" button in the cloud console.

[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 👉 [email protected]. Thanks!