using metadata_startup_script and changing machine_type and metadata at the same time fails

[natedogith1]

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

v1.2.3 on linux_amd64

Affected Resource(s)

• google_compute_instance

Terraform Configuration Files

resource "google_compute_instance" "default" {
  project = local.project_id
  zone = local.zone
  name = local.name
  allow_stopping_for_update = true
  machine_type = "e2-standard-4"
  metadata = {
    test_value = "abc"
  }
#   machine_type = "n2-standard-4"
#   metadata = {
#    test_value = "def"
#   }
  metadata_startup_script = "echo test"

  boot_disk {
    initialize_params {
      type  = "pd-standard"
      image = local.boot_image
      size  = local.boot_size
    }
    kms_key_self_link = local.boot_kms
  }

  network_interface {
    network    = local.network
    subnetwork = local.subnetwork
  }

  service_account {
    email  = local.service_account_email
    scopes = local.service_account_scopes
  }

  shielded_instance_config {
    enable_secure_boot = true
    enable_vtpm = true
    enable_integrity_monitoring = true
  }
}

Plan Output

  # google_compute_instance.default will be updated in-place
  ~ resource "google_compute_instance" "default" {
        id                        = "projects/<project>/zones/europe-west3-b/instances/metadata-test"
      ~ machine_type              = "e2-standard-4" -> "n2-standard-4"
      ~ metadata                  = {
          ~ "test_value" = "abc" -> "def"
        }
        name                      = "metadata-test"
        tags                      = []
        # (17 unchanged attributes hidden)
        # (5 unchanged blocks hidden)
    }

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

Expected Behavior

Metadata and machine type are changed without issue.

Actual Behavior

│ Error: Error starting instance: Error creating metadata: Cannot provide both metadata_startup_script and metadata.startup-script.
│
│   with google_compute_instance.default,
│   on simple.tf line 24, in resource "google_compute_instance" "default":
│   24: resource "google_compute_instance" "default" {
│

Steps to Reproduce

1. terraform apply
2. Change machine_type and metadata
3. terraform apply

Workaround

Change machine_type and metadata in two separate steps, or manually shut down the VM.

[edwardmedia]

@natedogith1 below is the error. I don't think it has anything related to the machine_type. Can you try by removing metadata_startup_script at the same time?

Cannot provide both metadata_startup_script and metadata.startup-script.

[natedogith1]

I haven't modified metadata_startup_script. Changing machine_type + metadata is where I saw the issue, but I suspect anything that triggers a machine restart (anything documented as needing allow_stopping_for_update) + metadata would also trigger it.

[edwardmedia]

@natedogith1 because you chose to update the machine_type, the apply will first stop the instance and then apply the changes. Ideally the process will restart the instance once the changes are applied. But in your case, it fails in restarting the instance because of below reason. This is controlled by API. Does this make sense?

Cannot provide both metadata_startup_script and metadata.startup-script.

[natedogith1]

That is the bug. I'm not providing metadata.startup-script, I'm only providing metadata_startup_script.

[edwardmedia]

@natedogith1 the provider re-organizes the payload. It converts metadata_startup_script to metadata.startup-script. Can you share your debug log? We can review it if that is the case.

[natedogith1]

Here's the results of the tests I did TF_LOG=DEBUG. There's probably a bunch of extra irrelevant data, since there were other terraform files in the folder that weren't changed.
This one has the error: metadata_fail_trimmed.log
This one, for comparison, had the VM stopped before the apply was run: metadata_stopped_vm_trimmed.log

[edwardmedia]

@natedogith1 do you notice below block in the payload? Basically when the instance restarts, the server side sees both were set which is against its business rule. There is not much we can do at the provider level. Does this make sense?

 "metadata": {
  "kind": "compute#metadata",
  "fingerprint": "xfv6fzzPOO8=",
  "items": [
   {
    "key": "startup-script",
    "value": "echo test"
   },
   {
    "key": "test_value",
    "value": "def"
   }
  ]
 },

[natedogith1]

Where do you see both being set on the server side? To my knowledge, only metadata.startup-script exists in GCP, with the provider converting metadata_startup_script to metadata.startup-script. Also, I think that section is the same in both the failed restart log and the successful log where the VM was already shut down.

[edwardmedia]

@natedogith1 now I see where the problem is. The provider saves the metadata_startup_script to metadata.startup-script in the initial apply. Whenever metadata needs to be updated, the provider sees the existence of both metadata_startup_script and metadata.startup-script which triggers this problem.

[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.