Unexpected Breaking Change: google_compute_instance addition of resource_policies

[tgoodsell-tempus]

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 a user, that user is claiming responsibility for the issue.
• Customers working with a Google Technical Account Manager or Customer Engineer can ask them to reach out internally to expedite investigation and resolution of this issue.

Terraform Version & Provider Version(s)

https://github.com/hashicorp/terraform-provider-google/releases/tag/v6.3.0 causes the breaking change

Affected Resource(s)

google_compute_instance

Terraform Configuration

resource "google_compute_instance" "main" {

  name         = "name"
  machine_type = "e2-standard-4"
  zone         = "us-central1-a"

  boot_disk {
    dynamic "initialize_params" {
      for_each = var.image_source != null ? ["this"] : []
      content {
        image = var.image_source
        size  = var.boot_disk_size
        type  = var.boot_disk_type
      }
    }
  }
}

resource "google_compute_disk_resource_policy_attachment" "this" {

  name    = var.boot_disk_snapshot_policy
  disk    = google_compute_instance.main.name # The name of the boot disk defaults to the name of the instance, assuming that pattern here.
  zone    = google_compute_instance.main.zone
  project = google_compute_instance.main.project
}

Debug Output

      ~ boot_disk {
          ~ device_name                = "persistent-disk-0" -> (known after apply)
          + disk_encryption_key_sha256 = (known after apply)
          + kms_key_self_link          = (known after apply)
          ~ source                     = "https://www.googleapis.com/compute/v1/projects/project-id/zones/us-west1-a/disks/test-cloud-dev" -> (known after apply)
            # (2 unchanged attributes hidden)

          ~ initialize_params {
              - enable_confidential_compute = false -> null
              ~ image                       = "https://www.googleapis.com/compute/v1/projects/ubuntu-os-cloud/global/images/ubuntu-2204-jammy-v20240315a" -> "ubuntu-os-cloud/ubuntu-2204-lts"
              ~ labels                      = {} -> (known after apply)
              ~ provisioned_iops            = 0 -> (known after apply)
              ~ provisioned_throughput      = 0 -> (known after apply)
              - resource_manager_tags       = {} -> null
              - resource_policies           = [ # forces replacement
                  - "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/resourcePolicies/test-snapshot",
                ] -> null
                # (2 unchanged attributes hidden)
            }
        }

Expected Behavior

Prior to this release, using the google_compute_disk_resource_policy_attachment policy was the main tool we could use for adding a snapshot policy to the bootdisk of an instance.

We would expect that the use of that pattern would not break with the release of a new field.

Actual Behavior

Per the debug, this causes a conflict between the config for google_compute_instance and the state of the GCE resource when used with google_compute_disk_resource_policy_attachment.

I would have expected to have that field be both a:

1. Not a forceNew, since clearly we can add in the resource policy and destroy it without affecting the instance itself
2. A computed field (or other mechanism) since this value can be set by this resource

Steps to reproduce

1. Create a instance, snapshot policy, and then link the boot disk using a google_compute_disk_resource_policy_attachment resource.
2. Run a plan / apply and view the conflict.

Important Factoids

No response

References

Change which caused this: GoogleCloudPlatform/magic-modules#11527

b/369404586

[karolgorc]

Confirmed this diff. Working on a fix.

Setting the field as Computed will fix the issue but not sure about removing the ForceNew.

This field is under initialize_params which by name implies that if any parameters are changed the instance will be reinitialized. Not sure if we can even update that without ForceNew but it would be an out of pattern behavior even if we can.

[ggtisc]

I can't reproduce the issue and see the permadiff, but apparently multiple users are having the same issue

[karolgorc]

Hi @ggtisc, Here is a clean config to recreate this diff. Just to clarify that it exists.

1. terraform apply
2. terraform apply without any changes

Terraform v1.9.5
on linux_amd64

• provider registry.terraform.io/hashicorp/google v6.4.0
• provider registry.terraform.io/hashicorp/google-beta v6.4.0

resource "google_compute_resource_policy" "test-policy" {
  name = "test-policy"
  snapshot_schedule_policy {
    schedule {
      hourly_schedule {
        hours_in_cycle = 1
        start_time     = "11:00"
      }
    }
  }
}

resource "google_compute_instance" "test-instance" {
  name = "test-instance"
  machine_type = "n1-standard-1"
  zone = var.zone
  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }
  network_interface {
    network = "default"
  }
}

resource "google_compute_disk_resource_policy_attachment" "this" {
  name    = google_compute_resource_policy.test-policy.name
  disk    = google_compute_instance.test-instance.name
  zone    = google_compute_instance.test-instance.zone
  project = google_compute_instance.test-instance.project
}

You can get rid of this diff by setting boot_disk.initialize_params.resource_policies to the same value as in the attachment hence it needs to be Computed: true,

boot_disk {
    initialize_params {
      resource_policies = [ google_compute_resource_policy.test-policy.id ]
      image = "debian-cloud/debian-11"
    }
  }

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