Trying to migrate google_compute_attached_disk.files_db from pd-standard to pd-ssd modify sellf-link from short to long URI

[thomasboussekey]

Hello,

Using the following configuration:
Terraform v0.11.7

• provider.google v1.20.0

I try to perform a in-place disk migration from pd-standard to pd-ssd

Here is an extract of my terraform :

resource "google_compute_attached_disk" "files_db" {
  disk     = "${element(google_compute_disk.files.*.self_link, count.index)}"
  instance = "${element(google_compute_instance.db.*.self_link, count.index)}"
  count    = "${var.count * var.has_lo_tablespace}"
  device_name = "files"
}

resource "google_compute_instance" "db" {
  count                   = "${var.count}"
  name                    = "${local.tenant_name}-db${count.index + 1}"
  description             = "${local.tenant_name} DB instance number ${count.index + 1}"
  zone                    = "${element(sort(data.google_compute_zones.availables.names), count.index)}"
  machine_type            = "${var.db_instance_type}"
  allow_stopping_for_update = true
  metadata                = "${merge(local.metadata, map("name", "${local.tenant_name}-db${count.index + 1}"))}"
  can_ip_forward          = true
  tags                    = ["allow-ssh-target", "allow-postgres-target", "allow-${local.tenant_name}"]
  metadata_startup_script = "${element(data.template_file.startup-script.*.rendered, count.index)}"

  boot_disk {
    initialize_params {
      size  = "${var.root_volume_size}"
      type  = "pd-standard"
      image = "${local.instance_image}"
    }
  }

  # Note: When using compute_attached_disk you must use lifecycle.ignore_changes = ["attached_disk"] on the compute_instance 
  # resource that has the disks attached. Otherwise the two resources will fight for control of the attached disk block.
  lifecycle {
    ignore_changes = ["attached_disk"]
  }
}

resource "google_compute_disk" "files" {
  #count = "${local.int_lo_disk_count}"
  count = "${var.count * var.has_lo_tablespace}"
  name  = "${local.tenant_name}-files-${count.index + 1}"
  zone  = "${element(sort(data.google_compute_zones.availables.names), count.index)}"
  size  = "${var.tablespace_volume_size}"
  type  = "${var.tablespace_volume_type}"
}

I can increase the size of my files google_compute_disk without recreating the google_compute_disk resource.
Yet, when I try to change the disk type I have new resource required notifications

Here is the terraform apply log:

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

-/+ google_compute_attached_disk.files_db[0] (new resource required)
      id:                         "tboussekey-test-db1:tboussekey-test-files-1" => <computed> (forces new resource)
      device_name:                "files" => "files"
      disk:                       "projects/gke-test-eu-1-proj-14b36a8c/zones/europe-west1-b/disks/tboussekey-test-files-1" => "${element(google_compute_disk.files.*.self_link, count.index)}" (forces new resource)
      instance:                   "projects/gke-test-eu-1-proj-14b36a8c/zones/europe-west1-b/instances/tboussekey-test-db1" => "https://www.googleapis.com/compute/v1/projects/gke-test-eu-1-proj-14b36a8c/zones/europe-west1-b/instances/tboussekey-test-db1"
      mode:                       "READ_WRITE" => "READ_WRITE"
      project:                    "gke-test-eu-1-proj-14b36a8c" => <computed>
      zone:                       "europe-west1-b" => <computed>

-/+ google_compute_attached_disk.files_db[1] (new resource required)
      id:                         "tboussekey-test-db2:tboussekey-test-files-2" => <computed> (forces new resource)
      device_name:                "files" => "files"
      disk:                       "projects/gke-test-eu-1-proj-14b36a8c/zones/europe-west1-c/disks/tboussekey-test-files-2" => "${element(google_compute_disk.files.*.self_link, count.index)}" (forces new resource)
      instance:                   "projects/gke-test-eu-1-proj-14b36a8c/zones/europe-west1-c/instances/tboussekey-test-db2" => "https://www.googleapis.com/compute/v1/projects/gke-test-eu-1-proj-14b36a8c/zones/europe-west1-c/instances/tboussekey-test-db2"
      mode:                       "READ_WRITE" => "READ_WRITE"
      project:                    "gke-test-eu-1-proj-14b36a8c" => <computed>
      zone:                       "europe-west1-c" => <computed>

-/+ google_compute_disk.files[0] (new resource required)
      id:                         "tboussekey-test-files-1" => <computed> (forces new resource)
      creation_timestamp:         "2019-06-05T08:35:41.551-07:00" => <computed>
      disk_encryption_key.#:      "0" => <computed>
      disk_encryption_key_sha256: "" => <computed>
      label_fingerprint:          "42WmSpB8rSM=" => <computed>
      last_attach_timestamp:      "2019-06-05T08:35:53.733-07:00" => <computed>
      last_detach_timestamp:      "" => <computed>
      name:                       "tboussekey-test-files-1" => "tboussekey-test-files-1"
      project:                    "gke-test-eu-1-proj-14b36a8c" => <computed>
      self_link:                  "https://www.googleapis.com/compute/v1/projects/gke-test-eu-1-proj-14b36a8c/zones/europe-west1-b/disks/tboussekey-test-files-1" => <computed>
      size:                       "400" => "400"
      source_image_id:            "" => <computed>
      source_snapshot_id:         "" => <computed>
      type:                       "pd-ssd" => "pd-standard" (forces new resource)
      users.#:                    "1" => <computed>
      zone:                       "europe-west1-b" => "europe-west1-b"

-/+ google_compute_disk.files[1] (new resource required)
      id:                         "tboussekey-test-files-2" => <computed> (forces new resource)
      creation_timestamp:         "2019-06-05T08:35:41.846-07:00" => <computed>
      disk_encryption_key.#:      "0" => <computed>
      disk_encryption_key_sha256: "" => <computed>
      label_fingerprint:          "42WmSpB8rSM=" => <computed>
      last_attach_timestamp:      "2019-06-05T08:35:54.017-07:00" => <computed>
      last_detach_timestamp:      "" => <computed>
      name:                       "tboussekey-test-files-2" => "tboussekey-test-files-2"
      project:                    "gke-test-eu-1-proj-14b36a8c" => <computed>
      self_link:                  "https://www.googleapis.com/compute/v1/projects/gke-test-eu-1-proj-14b36a8c/zones/europe-west1-c/disks/tboussekey-test-files-2" => <computed>
      size:                       "400" => "400"
      source_image_id:            "" => <computed>
      source_snapshot_id:         "" => <computed>
      type:                       "pd-ssd" => "pd-standard" (forces new resource)
      users.#:                    "1" => <computed>
      zone:                       "europe-west1-c" => "europe-west1-c"


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

Is it possible to upgrade in-place my disk type?

Thanks in advance for your help,
Regards,
Thomas

[chrisst]

Sorry, it is not possible to change your disk type in place.

[thomasboussekey]

OK, Thanks @chrisst for you quick reply!

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!