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

google_compute_instance : min_cpu_platform issue when setted to "empty" #4975

Closed
kdefives opened this issue Nov 22, 2019 · 5 comments · Fixed by GoogleCloudPlatform/magic-modules#2743
Assignees
Labels

Comments

@kdefives
Copy link

kdefives commented Nov 22, 2019

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment
  • If an issue is assigned to the "modular-magician" user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to "hashibot", a community member has claimed the issue already.

Terraform Version

Terraform v0.12.16

  • provider.google v3.0.0-beta.1

Affected Resource(s)

  • google_compute_instance

Terraform Configuration Files

provider "google" {
  credentials = base64decode("[**SECRET**]")
  project     = "[MY_PROJECT_ID]"
  region      = "europe-west4"
}

data "google_compute_image" "image" {
  family  = "windows-2019"
  project =  "windows-cloud"
}


resource "google_compute_instance" "instancewindows" {

  name           = "test2"
  machine_type   = "n2-standard-4"
  zone           = "europe-west4-b"
  project        = "[MY_PROJECT_ID]"
  can_ip_forward = "0"

  boot_disk {
    initialize_params {
      image = data.google_compute_image.image.self_link
      size  = "50"
      type  = "pd-standard"
    }
  }

  network_interface {
    network = "default"
  }

  metadata = {
    serial-port-enable = 1
  }
}

Debug/Info Output

https://gist.github.com/kdefives/03e51e0914deaa5c704b6445b7e351be

Expected Behavior

The second "terraform plan" should do no change at all.

Actual Behavior

When i do the plan / apply, everything is working worrectly. But when i redo a plan, even if nothing change in the terraform stack, the provider want to do a change for the min_cpu_platform even if i did not setted the min_cpu_platform into my stack.

As you can see in the result of the second "terraform plan", terraform try to do this change (see below). In my opinion, it is not normal because i did not specified the min_cpu_platform, this value is "computed" by GCP during the resource creation...

~ update in-place

Terraform will perform the following actions:

  # google_compute_instance.instancewindows will be updated in-place
  ~ resource "google_compute_instance" "instancewindows" {
        ......
      - min_cpu_platform     = "Intel Cascade Lake" -> null
        ......

Steps to Reproduce

By using my code above (by replacing secret to declare the provider)

  1. terraform apply
  2. terraform plan

Workaround

Currently i will force the min_cpu_platform parameter to avoid this issue. But from my point of view it is not a good way to do (even more in production...), because it means that i have to provision the resource first whitout the parameter in order to know which cpu_platform GCP will choose. Then, i have to update my stack by adding the value used by GCP and redo a plan/apply to be "clean".

I discover this problem by using Terraform v0.11.14 with provider.google v2.20.0 because we cannot use Terraform v0.12 in production.

Thanks in advance for your help.
Let me know if you need more informations.
Regards

@slevenick
Copy link
Collaborator

Well that's not good. It seems like something within the API response has changed recently, because this didn't work this way in the past.

I'll fix this in an upcoming release

@slevenick slevenick self-assigned this Nov 22, 2019
@slevenick
Copy link
Collaborator

slevenick commented Nov 22, 2019

I think this may not be caused by a change in the API, but rather the specific machine type that you are using. n2-standard-4 seems to only be supported by Intel Cascade Lake CPU platforms (see https://cloud.google.com/compute/docs/machine-types), so it somewhat makes sense that the API returns that value.

Were you able to run this configuration in the past successfully?

In any case, you can either specify the min_cpu_platform OR declare that you don't care what value it is with ignore_changes on a lifecycle block: https://www.terraform.io/docs/configuration/resources.html#lifecycle-lifecycle-customizations

@slevenick
Copy link
Collaborator

This field will default to the value set by the API if it is not specified with the release of 3.1.0 of the provider. Until then, the mitigations in my previous comment apply

@kdefives
Copy link
Author

Were you able to run this configuration in the past successfully?

This is the first time i run this configuration so i cannot say.

In any case, you can either specify the min_cpu_platform OR declare that you don't care what value it is with ignore_changes on a lifecycle block: https://www.terraform.io/docs/configuration/resources.html#lifecycle-lifecycle-customizations

Yes, this is what we are doing for the moment until the fix will be released.

Thx

@ghost
Copy link

ghost commented Mar 29, 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 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants