Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

automatic_restart false in scheduling/google_compute_instance_template forces new resource #224

Closed
dgolja opened this issue Jul 20, 2017 · 3 comments · Fixed by #248
Closed
Labels
forward/review In review; remove label to forward service/compute-instances

Comments

@dgolja
Copy link

dgolja commented Jul 20, 2017

Hi there,

If in google_compute_instance_template you define scheduling block automatic_restart = false, terraform will always recreate the resource trying to update automatic_restart field to true.

Terraform Version

Terraform v0.9.11

Affected Resource(s)

  • google_compute_instance_template

Terraform Configuration Files

...
resource "google_compute_instance_template" "instance_template" {
  name_prefix = "dgolja-instance-template-tf-bug-"

  region = "${var.region}"

  lifecycle {
    create_before_destroy = true
  }

  machine_type         = "n1-standard-1"
  can_ip_forward       = false

  scheduling {
    automatic_restart   = false
    on_host_maintenance = "MIGRATE"
  }

  network_interface {
    network = "default"
  }

  disk {
    source_image = "projects/ubuntu-os-cloud/global/images/ubuntu-1604-xenial-v20170619a"
    disk_type    = "pd-ssd"
    auto_delete  = true
    boot         = true
  }

  service_account {
    scopes = ["userinfo-email"]
  }
}
...

Debug Output

https://gist.github.com/dgolja/1c80d16db90d9bbea5fa1cce21d9f8f9

Expected Behavior

Since there is no change terraform shouldn't recreate the resource.

Actual Behavior

Keep updating the resource, however the new resource is the same.

Steps to Reproduce

  1. terraform apply
@dgolja dgolja changed the title if automatic_restart = false in scheduling/google_compute_instance_template resource get recreated automatic_restart false in scheduling/google_compute_instance_template triggers resource recreation Jul 20, 2017
@dgolja dgolja changed the title automatic_restart false in scheduling/google_compute_instance_template triggers resource recreation automatic_restart false in scheduling/google_compute_instance_template forces new resource Jul 20, 2017
@dgolja
Copy link
Author

dgolja commented Jul 21, 2017

Workaround for tf v9.11 is to use a deprecated parameter automatic_restart and set it to false.

Also after digging into the code I noticed that deprecated automatic_restart value will always get overwritten if scheduling.automatic_restart is defined, so you can end up in really bizarre state. L514-L516 L532-L535

My recommendation would be to remove the automatic_restart parameter from the state file. This should fix the problem. The value of automatic_restart get already stored in the state file anyway under scheduling.automatic_restart

@selmanj
Copy link
Contributor

selmanj commented Aug 9, 2017

Thanks for reporting, hopefully #248 fixes this for you.

luis-silva pushed a commit to luis-silva/terraform-provider-google that referenced this issue May 21, 2019
@ghost
Copy link

ghost commented Mar 31, 2020

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!

@ghost ghost locked and limited conversation to collaborators Mar 31, 2020
@github-actions github-actions bot added forward/review In review; remove label to forward service/compute-instances labels Jan 14, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
forward/review In review; remove label to forward service/compute-instances
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants