Changing label of boot disk forces replacement of instance

[derhally]

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 1.3.8
provider google 5.0.0

Affected Resource(s)

• google_compute_instance

Terraform Configuration Files

resource "google_compute_instance" "instance" {
  name         = "foo"
  machine_type = var.instance_type
  zone         = var.availability_zone


  boot_disk {
    initialize_params {
      image  = var.base_image
      size   = local.boot_size
      type   = local.boot_type
      labels = {
        my_label = "foo"
      }
    }
  }

Debug Output

Expected Behavior

Update the labels of the boot disk in place without recreating the VM.

This is what many people expect to happen. There is no good reason why this should cause the VM to be recreated just for updating labels on the disk. This can easily be missed and lead to data loss.

To add more context. Our developers have read only access to the GCP console in certain environments, so for them to workaround this they would need to elevate their access to go and update the disk in the UI. This is a lot of work extra work and causes a disruption to the workflow.

In a medium sized terraform workspace with different types of resources that share the same label set, this small change may cause the recreation to go unnoticed. This has happened multiple times.

I don't know of any other GCP resources that need to be recreated for changing labels, so this single scenario can have catastrophic side effects.

Actual Behavior

The provider wants to recreate the VM just to update the labels of the boot disk.

Steps to Reproduce

1. terraform apply
2. Change the boot disk label value to "bar"
3. terraform plan

Important Factoids

References

Terraform docs regarding intialize_params are here

b/321524195

[schaabm]

Workaround for that:

• Adjust or create the label manually at the disk within the GCP UI
• change your Terraform code
• make a plan or apply

nothing should be change at the instance

[edwardmedia]

@derhally what version of the provider are you using? Can you share the debug log that contains the api requests and responses?

[derhally]

@derhally what version of the provider are you using? Can you share the debug log that contains the api requests and responses?

We have reproduced in both the 4.x and 5.x provider. Sorry can't share debug logs at this time. I believe this behavior has been around even in the older providers

[edwardmedia]

@derhally I think you are right. The labels currently is set as ForceNew.

It looks like update is available from the api.

compute.disks.setLabels

[mwarkentin]

I believe this is similar to #6087

[rileykarson]

This is intended behaviour, as initialize_params is in use. Rather than persistent settings for the resource initialize_params indicates "these are the settings the resource should have been created with". Generally we'd recommend initialize_params for simple "create-on-create" flows where a basic disk should be created alongside the instance, and more complicated flows where the disk will need to be updated in the future should use boot_disk.0.source to reference a disk resource that's defined as a top-level resource in the same configuration.

I'll admit that this stance is a little obtuse- initialize_params is the most Console-like flow for the resource. The different workflows between the tools (Terraform is stateful and declarative, Console is stateless and switches between declarative/imperative depending on context) make it difficult to keep parity with Console's representation of resources, though, and that's a non-goal for the provider. Instead, being a relatively complete API client is.

[ricardoklein]

Sorry, this is, IMHO, bad!

Changing the label of a resource should never recreate it. What if you add the "application ID", "owner", "billing/cost center" information in the disk labels and they need to be changed?

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