Source Image repeatedly "changed"

[MaikJaek]

Hi there,

after creating a HA NAT Gateway setup using the give module, we experience the following behaviour lately:

Even though, we haven't changed our code at all, suddenly tfplan outputs the following change:

-/+ module.nat-zone-2.module.nat-gateway.google_compute_instance_template.default (new resource required) id: "default-20180920175925090000000001" => <computed> (forces new resource) can_ip_forward: "true" => "true" disk.#: "1" => "1" disk.0.auto_delete: "true" => "true" disk.0.boot: "true" => "true" disk.0.device_name: "persistent-disk-0" => <computed> disk.0.disk_size_gb: "0" => "0" disk.0.disk_type: "pd-ssd" => "pd-ssd" disk.0.interface: "SCSI" => <computed> disk.0.mode: "READ_WRITE" => <computed> disk.0.source_image: "projects/debian-cloud/global/images/family/debian-9" => "debian-cloud/debian-9" (forces new resource) disk.0.type: "PERSISTENT" => "PERSISTENT" machine_type: "n1-standard-1" => "n1-standard-1" metadata.%: "2" => "2"

Even when we recreate the NAT-Gateways, upon executing the next "tfplan" this pending change is reported again. I'm assuming that the referenced "debian-cloud/debian-9" is internally mapped to a fully qualified name called "projects/debian-cloud/global/images/family/debian-9" upon creation.

Can you confirm and fix the issue please?
My suggestion is to change the image to the long name --> projects/debian-cloud/global/images/family/debian-9

Thanks!
Maik

[petervandenabeele]

Are you seeing that today (24 Sept) each new terraform apply requires a "new resource" even when nothing changed?

I did not see that problem a few days ago, with same or very similar code. I tried reverting to provider google 1.17, but that did not seem to solve the problem.

Do you think this is related to the debian-cloud naming (or change thereof ?). Thanks :-)

[jbanton-dm]

I was having this issue as well. If you set the compute_image = "projects/debian-cloud/global/images/family/debian-9" manually it will stop trying to rebuild the instance. I've also opened a PR changing the variable to avoid this workaround.

#93

[MaikJaek]

Thanks @jbanton-dm . This temporarily fixed it for us.
Nevertheless, the mentioned fix #93 should be merged.

[danisla]

I'm going to apply a similar change to the managed-instance-group module which has the same issue.