google_compute_instance can not unset min_cpu_platform

[philip-harvey]

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

1.44
Google provider 4.69.1

Affected Resource(s)

• google_compute_instance

Terraform Configuration Files

resource "google_compute_instance" "test" {
  name                      = "test"
  machine_type              = "n1-standard-1"  # can be any machine type that you can set min_cpu_platform for, issue is not specific to n1
  min_cpu_platform          = "Intel Broadwell"  # this can be any min_cpu_platform that is valid for the machine_type you are using
  zone                      = "us-central1-a"  # can be any zone
  allow_stopping_for_update = true
  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"  # can be any boot disk to reproduce the issue
    }
  }
network_interface {   # can be any network to reproduce the issue
    network = "default"
    access_config {
      // Ephemeral public IP
    }
  }
}

Expected Behavior

Terraform should unset min_cpu_platform when you set it to null or delete it from Terraform.

Actual Behavior

Terraform fails to unset min_cpu_platform when you set it to null or delete it from Terraform. This means you can never change to another instance type using Terraform if you set min_cpu_platform via Terraform.

Error: googleapi: Error 400: Setting minimum CPU platform is not supported for the selected machine type XXXX badRequest

Steps to Reproduce

1. terraform apply
2. change machine_type to anything else in another machine type (i.e. anything that is not the same machine type as you did in your first apply). e.g. e2-standard-2
3. delete the line min_cpu_platform = "Intel Broadwell" OR set min_cpu_platform = null OR set min_cpu_platform = "" OR set min_cpu_platform = "AUTOMATIC"
4. terraform apply

Important Factoids

I think this is caused by GoogleCloudPlatform/magic-modules#2743
You can never change to another instance type using Terraform if you set min_cpu_platform via Terraform.

References

(https://github.com/GoogleCloudPlatform/magic-modules/pull/2743)](https://github.com/GoogleCloudPlatform/magic-modules/pull/2743)

[edwardmedia]

@philip-harvey just curious, can you unset it via console or gcloud?

[philip-harvey]

@philip-harvey just curious, can you unset it via console or gcloud?

Definitely can unset it via Console and GCloud and API, it's documented here:
https://cloud.google.com/compute/docs/instances/specify-min-cpu-platform#resetminplatform

To remove the setting is to simply set it to "AUTOMATIC", but this fails with Terraform currently

[edwardmedia]

@philip-harvey not sure what happened in your case (to remove the setting is to simply set it to "AUTOMATIC", but this fails with Terraform currently).

Using your config, I am able to Removing a minimum CPU platform setting by providing AUTOMATIC. Do you want to share your debug log so I can take a closer look?

resource "google_compute_instance" "test" {
  name                      = "issue14945"
  machine_type              = "n1-standard-1"  # can be any machine type that you can set min_cpu_platform for, issue is not specific to n1
  //min_cpu_platform          = "Intel Broadwell"  # this can be any min_cpu_platform that is valid for the machine_type you are using
  min_cpu_platform          = "AUTOMATIC"
  zone                      = "us-central1-a"  # can be any zone
  allow_stopping_for_update = true
  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"  # can be any boot disk to reproduce the issue
    }
  }
network_interface {   # can be any network to reproduce the issue
    network = "default"
    access_config {
      // Ephemeral public IP
    }
  }
}

[philip-harvey]

@philip-harvey not sure what happened in your case (to remove the setting is to simply set it to "AUTOMATIC", but this fails with Terraform currently).

Using your config, I am able to Removing a minimum CPU platform setting by providing AUTOMATIC. Do you want to share your debug log so I can take a closer look?

resource "google_compute_instance" "test" {
  name                      = "issue14945"
  machine_type              = "n1-standard-1"  # can be any machine type that you can set min_cpu_platform for, issue is not specific to n1
  //min_cpu_platform          = "Intel Broadwell"  # this can be any min_cpu_platform that is valid for the machine_type you are using
  min_cpu_platform          = "AUTOMATIC"
  zone                      = "us-central1-a"  # can be any zone
  allow_stopping_for_update = true
  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"  # can be any boot disk to reproduce the issue
    }
  }
network_interface {   # can be any network to reproduce the issue
    network = "default"
    access_config {
      // Ephemeral public IP
    }
  }
}

Hi @edwardmedia you are changing to a type that supports min_cpu_platform , try setting to a type that doesn't such as e2, it's not possible with Terraform. I wasn't clear about that in my description, sorry.

[edwardmedia]

@philip-harvey did you say you are able to unset min_cpu_platform for e2 via console or gcloud? It seems that is the rule set by the api. Do you want detail the steps what you can do via console and gcloud?

[philip-harvey]

Via the console it's trivial, set min_cpu_platform to Automatic and then set the machine type and click save. The issue seems to be that Terraform doesn't unset min_cpu_platform when you delete the value for min_cpu_platform or set to null like you would expect.
Even if I try to do the change in 2 steps with Terraform it doesn't work since it fails to unset min_cpu_platform, so if you set this once via Terraform it can never be undone with Terraform

[edwardmedia]

It looks like you are right there are limitations for using min_cpu_platform

[edwardmedia]

I can repro this issue. Below is the plan I got. Apply this plan, the provider is supposed to call the api with two steps. Because setMachineType is called before setMinCpuPlatform, it errors out as min_cpu_platform is still in place. Possible fix would be to switch the sequence of execution

  # google_compute_instance.test will be updated in-place
  ~ resource "google_compute_instance" "test" {
        id                        = "projects/myproject/zones/us-central1-a/instances/issue14945"
      ~ machine_type              = "n1-standard-1" -> "e2-micro"
      ~ min_cpu_platform          = "Intel Broadwell" -> "AUTOMATIC"
        name                      = "issue14945"
        tags                      = []
        # (17 unchanged attributes hidden)

        # (4 unchanged blocks hidden)
    }

[melinath]

min_cpu_platform was marked as an optional + computed field, because the API returns a value even if you don't set one. This results in the behavior described: the previous value will keep being sent to the API as long as the API keeps returning it. This is part of how Terraform core treats optional + computed fields.

If the default from the API is always AUTOMATIC (and/or if that will always be a valid value) we could change the field to have Default: "AUTOMATIC" instead of Computed; however, that would be a breaking change.

But I think that @edwardmedia is correct that we can improve the behavior by switching the update order. I don't think that will change the behavior for empty values but it should at least make it so that AUTOMATIC is honored.

[github-actions]

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.