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

Can not change google_compute_instance machine_type when min_cpu_platform is set #15471

Open
philip-harvey opened this issue Aug 10, 2023 · 4 comments · May be fixed by GoogleCloudPlatform/magic-modules#11289

Comments

@philip-harvey
Copy link

philip-harvey commented Aug 10, 2023

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 v1.5.2
google v4.77.0

Affected Resource(s)

google_compute_instance

Terraform Configuration Files

Before:

resource "google_compute_instance" "test" {
  name                      = "test"
  machine_type              = "n2d-standard-2"
  zone                      = "us-central1-a"
  min_cpu_platform          = "AMD Milan"
  allow_stopping_for_update = true
  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }
  network_interface {
    network = "default"
    access_config { }
  }
}

After:

resource "google_compute_instance" "test" {
  name                      = "test"
  machine_type              = "n2-standard-2"
  zone                      = "us-central1-a"
  min_cpu_platform          = "Intel Ice Lake"
  allow_stopping_for_update = true
  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }
  network_interface {
    network = "default"
    access_config { }
  }
}

Expected Behavior

GCE instance is stopped (if running), Instance type and min_cpu_platform are updated

Actual Behavior

Plan shows the correct change:

google_compute_instance.test will be updated in-place
  ~ resource "google_compute_instance" "test" {
        id                        = "projects/neon-sandbox-pharvey-ja0t/zones/us-central1-a/instances/test"
      ~ machine_type              = "n2d-standard-2" -> "n2-standard-2"
      ~ min_cpu_platform          = "AMD Milan" -> "Intel Ice Lake"
        name                      = "test"
        tags                      = []
        # (17 unchanged attributes hidden)

        # (4 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

but the apply fails with error "Error: googleapi: Error 400: The selected machine type (n2-standard-2) has a required CPU platform of cascadelake. The minimum CPU platform must match this, but was milan., badRequest"

Steps to Reproduce

  1. terraform apply of the "Before" code
  2. terraform apply of the "After" code

References

Similar issue to 14945

It is possible to work around this bug by doing a two step process. First change min_cpu_platform to "AUTOMATIC" and do an apply, then change to the new machine_type and min_cpu_platform

b/308755716

@edwardmedia
Copy link
Contributor

edwardmedia commented Aug 14, 2023

Interesting. Below is what I got. The api returns 200 but with error message. Should this be treated as successful or failure? @zli82016

 ---[ RESPONSE ]--------------------------------------
 HTTP/2.0 200 OK
 {
   "name": "projects/myproject/locations/global/operations/operation-1691939923148-602cf7619c02d-d9cc0af4-e88e40b5",
   "metadata": {
     "@type": "type.googleapis.com/google.cloud.networksecurity.v1beta1.OperationMetadata",
     "createTime": "2023-08-13T15:18:43.158956099Z",
     "endTime": "2023-08-13T15:18:43.278011003Z",
     "target": "projects/myproject/locations/global/serverTlsPolicies/issue15453",
     "verb": "update",
     "requestedCancellation": false,
     "apiVersion": "v1beta1"
   },
   "done": true,
   "error": {
     "code": 9,
     "message": "Update not supported for ServerTlsPolicy created for External Load Balancer"
   }
 }

@edwardmedia edwardmedia assigned zli82016 and unassigned roaks3 Aug 14, 2023
@philip-harvey
Copy link
Author

Interesting. Below is what I got. The api returns 200 but with error message. Should this be treated as successful or failure? @zli82016

 ---[ RESPONSE ]--------------------------------------
 HTTP/2.0 200 OK
 {
   "name": "projects/myproject/locations/global/operations/operation-1691939923148-602cf7619c02d-d9cc0af4-e88e40b5",
   "metadata": {
     "@type": "type.googleapis.com/google.cloud.networksecurity.v1beta1.OperationMetadata",
     "createTime": "2023-08-13T15:18:43.158956099Z",
     "endTime": "2023-08-13T15:18:43.278011003Z",
     "target": "projects/myproject/locations/global/serverTlsPolicies/issue15453",
     "verb": "update",
     "requestedCancellation": false,
     "apiVersion": "v1beta1"
   },
   "done": true,
   "error": {
     "code": 9,
     "message": "Update not supported for ServerTlsPolicy created for External Load Balancer"
   }
 }

Hi @edwardmedia That seems to be different to what I'm seeing, not sure why there would be a message about an ELB

@zli82016
Copy link
Collaborator

I got an error

googleapi: Error 400: The selected machine type (n2d-standard-2) has a required CPU platform of rome. The minimum CPU platform must match this, but was icelake., badRequest

@zli82016 zli82016 removed their assignment Aug 18, 2023
@github-actions github-actions bot added forward/review In review; remove label to forward service/compute-instances labels Oct 25, 2023
@edwardmedia edwardmedia removed the forward/review In review; remove label to forward label Oct 26, 2023
@karolgorc
Copy link

The provider works as intended. It’s the API that causes the extra step when changing machine_type and the min_cpu parameters

This was delegated to the Compute API team along with problems printing the correct platform names in the requests

Testing with gcloud

  • Creating a VM with min_cpu_platform AMD Milan

image

  • Stopping the VM

  • Trying to change min_cpu_platform

image

  • Trying to change machine_type

image

  • The min_cpu_platform must be set to AUTOMATIC . If not these 2 parameters block one another.

image

I think there should be a mention of the workaround in the error message that the user gets in terraform before this gets fixed in the API

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants