Compute v2: Enable Multiattach Volumes

[jtopjian]

This commit allows instances to attach multiattach volumes
by adding a new argument called "multiattach". When set, the
compute client will use Microversion 2.60, which enables multiattach
support in the Compute/Nova API.

For #432

@jamesmmccarthy I'm unable to test multiattach volumes at the moment, so I'm not sure if this works. Would you be able to give it a try? I've updated the documentation to include an example implementation, though I'm not sure if it's correct.

[theopenlab-ci]

Build succeeded.

• terraform-provider-openstack-unittest : SUCCESS in 4m 51s
• terraform-provider-openstack-acceptance-test : SUCCESS in 1h 43m 53s

[jamesmmccarthy]

Initial attempts at testing this PR seem to show it's not having the desired effect - will look into this further. (Also small typo in the doc section)

[jamesmmccarthy]

@jtopjian I have re-tested and found that this PR actually does work - it requires adding multiattach = true property to the attachment definition, looks like the doc typo is the only outstanding issue. Probably with terraform/IaC this is a normal requirement.

[jamesmmccarthy]

For completeness I also did a test where a single volume is attached to two instances. It required the use of depends_on for sanity, otherwise it worked well, like so:

$ openstack server list
+--------------------------------------+-------------+--------+----------------------+--------------+--------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------+--------+----------------------+--------------+--------+
| 60c521a6-837c-4e03-a81e-01d11662ca2e | myinstance2 | ACTIVE | public=10.196.223.11 | cirros-0.4.0 | |
| 7deb75a3-14a1-4ac6-943b-931f6c8f1161 | myinstance | ACTIVE | public=10.196.223.23 | cirros-0.4.0 | |
+--------------------------------------+-------------+--------+----------------------+--------------+--------+
$ openstack volume list
+--------------------------------------+-------+--------+------+-------------------------------------------------------------------------+
| ID | Name | Status | Size | Attached to |
+--------------------------------------+-------+--------+------+-------------------------------------------------------------------------+
| b35f8871-2392-4dc4-af78-0f86ddcebd41 | myvol | in-use | 1 | Attached to myinstance on /dev/vdb Attached to myinstance2 on /dev/vdb |
+--------------------------------------+-------+--------+------+-------------------------------------------------------------------------+

[jtopjian]

it requires adding multiattach = true property to the attachment definition, looks like the doc typo is the only outstanding issue

Where is the doc typo? The example in this PR has the following:

resource "openstack_compute_volume_attach_v2" "va_1" {
  instance_id = "${openstack_compute_instance_v2.instance_1.id}"
  volume_id   = "${openstack_blockstorage_volume_v2.volume_1.id}"
  multiattach = true
}

resource "openstack_compute_volume_attach_v2" "va_2" {
  instance_id = "${openstack_compute_instance_v2.instance_2.id}"
  volume_id   = "${openstack_blockstorage_volume_v2.volume_1.id}"
  multiattach = true
}

It required the use of depends_on for sanity

This makes sense. I'll update the PR to include this.

Thank you for testing this 😄

[jamesmmccarthy]

Typo: Line 151 * multiattach - (Optional) Enable attachment of multiattach-capabile volumes.
capabile ?

[jamesmmccarthy]

@jtopjian re: depends_on: the "va_2" resource would want something like:
depends_on = ["openstack_compute_volume_attach_v2.va_1"]

For reference, the depends_on is to avoid timing issues, and to prevent complaints such as:

• openstack_compute_volume_attach_v2.attached: Bad request with: [POST ... error message: {"badRequest": {"message": "Invalid input received: Invalid volume: Volume eec1ba0f-3900-425c-bf7e-490b5ad326c7 status must be available or in-use or downloading (HTTP 400) (Request-ID: req-2381cdd0-e013-49b7-b8a0-75a3ff3875bd)", "code": 400}}

Probably there are other terraform techniques to achieve similar, this was what I used for this testing.

Thanks for the updates ! 😄

[jtopjian]

Probably there are other terraform techniques to achieve similar, this was what I used for this testing.

I think for this situation, depends_on is the most appropriate solution. depends_on is the cleanest way of "serializing" Terraform.

[theopenlab-ci]

Build failed.

• terraform-provider-openstack-unittest : RETRY_LIMIT in 1m 00s
• terraform-provider-openstack-acceptance-test : RETRY_LIMIT in 1m 00s

[jtopjian]

recheck

[theopenlab-ci]

Build failed.

• terraform-provider-openstack-unittest : RETRY_LIMIT in 1m 00s
• terraform-provider-openstack-acceptance-test : SUCCESS in 2h 00m 22s

[jtopjian]

recheck

[theopenlab-ci]

Build succeeded.

• terraform-provider-openstack-unittest : SUCCESS in 2m 31s
• terraform-provider-openstack-acceptance-test : SUCCESS in 2h 30m 05s

[ozerovandrei]

Looks great