Modifying disks of an existing instance has no effect

[athak]

When an instance is created with multiple disks, the operation completes successfully and all requested volumes are present without issues.

When adding or removing disks to an existing instance, the operation appears to complete successfully but returns too quickly and nothing happens. The instance's disks remain the same but the state is updated.

In order to maintain consistency, we modify the instance in terraform and then add or remove the corresponding volumes from the panel which is very cumbersome and error prone, especially for removing a volume which implies first detaching it from the instance and then cancelling the volume itself.

Thanks,
Atha

[renier]

@athak Could you provide a sample terraform configuration file that can be used to recreate, and the list of terraform commands you perform?

[athak]

Hi @renier. Here is a sample config:

resource "softlayer_virtual_guest" "test" {
  hostname                 = "disk-test"
  domain                   = "dev.vurbia.net"
  datacenter               = "wdc04"
  os_reference_code        = "UBUNTU_16_64"
  cores                    = 1
  memory                   = 1024
  disks                    = [ 25, 25 ]
  local_disk               = false
  network_speed            = 100
}

Instance creation

terraform plan displays correctly:

+ softlayer_virtual_guest.test
    cores:                    "1"
    datacenter:               "wdc04"
    disks.#:                  "2"
    disks.0:                  "25"
    disks.1:                  "25"
    domain:                   "dev.vurbia.net"
    hostname:                 "disk-test"
    hourly_billing:           "true"
    ip_address_id:            "<computed>"
    ip_address_id_private:    "<computed>"
    ipv4_address:             "<computed>"
    ipv4_address_private:     "<computed>"
    ipv6_address:             "<computed>"
    ipv6_address_id:          "<computed>"
    ipv6_enabled:             "false"
    local_disk:               "false"
    memory:                   "1024"
    network_speed:            "100"
    os_reference_code:        "UBUNTU_16_64"
    private_network_only:     "false"
    private_subnet:           "<computed>"
    private_vlan_id:          "<computed>"
    public_ipv6_subnet:       "<computed>"
    public_subnet:            "<computed>"
    public_vlan_id:           "<computed>"
    secondary_ip_addresses.#: "<computed>"
    wait_time_minutes:        "90"

And terraform apply also executes without issues:

softlayer_virtual_guest.test: Creating...
  cores:                    "" => "1"
  datacenter:               "" => "wdc04"
  disks.#:                  "" => "2"
  disks.0:                  "" => "25"
  disks.1:                  "" => "25"
  domain:                   "" => "dev.vurbia.net"
  hostname:                 "" => "disk-test"
  hourly_billing:           "" => "true"
  ip_address_id:            "" => "<computed>"
  ip_address_id_private:    "" => "<computed>"
  ipv4_address:             "" => "<computed>"
  ipv4_address_private:     "" => "<computed>"
  ipv6_address:             "" => "<computed>"
  ipv6_address_id:          "" => "<computed>"
  ipv6_enabled:             "" => "false"
  local_disk:               "" => "false"
  memory:                   "" => "1024"
  network_speed:            "" => "100"
  os_reference_code:        "" => "UBUNTU_16_64"
  private_network_only:     "" => "false"
  private_subnet:           "" => "<computed>"
  private_vlan_id:          "" => "<computed>"
  public_ipv6_subnet:       "" => "<computed>"
  public_subnet:            "" => "<computed>"
  public_vlan_id:           "" => "<computed>"
  secondary_ip_addresses.#: "" => "<computed>"
  wait_time_minutes:        "" => "90"
softlayer_virtual_guest.test: Still creating... (10s elapsed)
softlayer_virtual_guest.test: Still creating... (20s elapsed)
softlayer_virtual_guest.test: Still creating... (30s elapsed)
...
softlayer_virtual_guest.test: Still creating... (6m20s elapsed)
softlayer_virtual_guest.test: Still creating... (6m30s elapsed)
softlayer_virtual_guest.test: Creation complete

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

The instance is created correctly with 2 volumes:

curl --silent --user user:api_key "https://api.service.softlayer.com/rest/v3/SoftLayer_Virtual_Guest/31846817.json?objectMask=hostname;domain;startCpus;maxMemory;blockDevices.diskImage.capacity" | jq

{
  "domain": "dev.vurbia.net",
  "hostname": "disk-test",
  "maxMemory": 1024,
  "startCpus": 1,
  "blockDevices": [
    {
      "diskImage": {
        "capacity": 25
      }
    },
    {
      "diskImage": {
        "capacity": 2
      }
    },
    {
      "diskImage": {
        "capacity": 25
      }
    }
  ]
}

Adding a disk

Changed disks parameter in .tf to disks = [ 25, 25, 25 ]

terraform plan displays:

~ softlayer_virtual_guest.test
    disks.#: "2" => "3"
    disks.2: "" => "25"

terraform apply returns almost immediately claiming success:

softlayer_virtual_guest.test: Modifying...
  disks.#: "2" => "3"
  disks.2: "" => "25"
softlayer_virtual_guest.test: Modifications complete

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

The state is modified since running a new plan yields:

State is updated!
No changes. Infrastructure is up-to-date. This means that Terraform
could not detect any differences between your configuration and
the real physical resources that exist. As a result, Terraform
doesn't need to do anything.

But the instance's disks remain the same:

curl --silent --user user:api_key "https://api.service.softlayer.com/rest/v3/SoftLayer_Virtual_Guest/31846817.json?objectMask=hostname;domain;startCpus;maxMemory;blockDevices.diskImage.capacity" | jq

{
  "domain": "dev.vurbia.net",
  "hostname": "disk-test",
  "maxMemory": 1024,
  "startCpus": 1,
  "blockDevices": [
    {
      "diskImage": {
        "capacity": 25
      }
    },
    {
      "diskImage": {
        "capacity": 2
      }
    },
    {
      "diskImage": {
        "capacity": 25
      }
    }
  ]
}

Removing disks

Changed disks parameter in .tf to disks = [ 25 ]
terraform plan displays:

~ softlayer_virtual_guest.test
    disks.#: "3" => "1"
    disks.1: "25" => "0"
    disks.2: "25" => "0"

terraform apply again returns almost immediately claiming success:

softlayer_virtual_guest.test: Modifying...
  disks.#: "3" => "1"
  disks.1: "25" => "0"
  disks.2: "25" => "0"
softlayer_virtual_guest.test: Modifications complete

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

The state is again modified since running a new plan yields the same:

State is updated!
No changes. Infrastructure is up-to-date. This means that Terraform
could not detect any differences between your configuration and
the real physical resources that exist. As a result, Terraform
doesn't need to do anything.

The instance's disks remain still the same:

curl --silent --user user:api_key "https://api.service.softlayer.com/rest/v3/SoftLayer_Virtual_Guest/31846817.json?objectMask=hostname;domain;startCpus;maxMemory;blockDevices.diskImage.capacity" | jq

{
  "domain": "dev.vurbia.net",
  "hostname": "disk-test",
  "maxMemory": 1024,
  "startCpus": 1,
  "blockDevices": [
    {
      "diskImage": {
        "capacity": 25
      }
    },
    {
      "diskImage": {
        "capacity": 2
      }
    },
    {
      "diskImage": {
        "capacity": 25
      }
    }
  ]
}

[igoraj]

We have also experienced this issue when modifying disk size on existing instance (e.g. increasing from 10G=>20G).

terraform plan displays the change correctly:

~ softlayer_virtual_guest.vsi
    disks.1: "10" => "20"

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

terraform apply finishes instantly:

softlayer_virtual_guest.vsi: Modifying... (ID: 1234567)
  disks.1: "10" => "20"
softlayer_virtual_guest.vsi: Modifications complete (ID: 1234567)

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

but API upon curl call on /rest/v3/SoftLayer_Virtual_Guest still returns:

    {
      "diskImage": {
        "capacity": 10
      }
    },

and actual disk was never changed although terraform thinks it was.