openstack_compute_volume_attach_v2

For your information

These instructions are an adapted copy of the official OpenStack Terraform provider documentation in the Terraform Registry.

Attaches a Block Storage Volume to an Instance using the OpenStack Compute (Nova) v2 API.

Example Usage⁠

Basic attachment of a single volume to a single instance⁠

resource "openstack_blockstorage_volume_v3" "volume_1" {
  name = "volume_1"
  size = 5
}

resource "openstack_compute_instance_v2" "instance_1" {
  name            = "instance_1"
  flavor_id       = "1311"
  image_id        = "<image-id>"
  security_groups = ["default"]
}

resource "openstack_compute_volume_attach_v2" "va_1" {
  instance_id = openstack_compute_instance_v2.instance_1.id
  volume_id   = openstack_blockstorage_volume_v3.volume_1.id
}

Attaching multiple volumes to a single instance⁠

resource "openstack_blockstorage_volume_v3" "volumes" {
  count = 2
  name  = format("vol-%02d", count.index + 1)
  size  = 5
}

resource "openstack_compute_instance_v2" "instance_1" {
  name            = "instance_1"
  flavor_id       = "1311"
  image_id        = "<image-id>"
  security_groups = ["default"]
}

resource "openstack_compute_volume_attach_v2" "attachments" {
  count       = 2
  instance_id = openstack_compute_instance_v2.instance_1.id
  volume_id   = openstack_blockstorage_volume_v3.volumes[count.index].id
}

output "volume_devices" {
  value = openstack_compute_volume_attach_v2.attachments.*.device
}

Note that the above example will not guarantee that the volumes are attached ina deterministic manner. The volumes will be attached in a seemingly randomorder.

If you want to ensure that the volumes are attached in a given order, createexplicit dependencies between the volumes, such as:

resource "openstack_blockstorage_volume_v3" "volumes" {
  count = 2
  name  = format("vol-%02d", count.index + 1)
  size  = 5
}

resource "openstack_compute_instance_v2" "instance_1" {
  name            = "instance_1"
  flavor_id       = "1311"
  image_id        = "<image-id>"
  security_groups = ["default"]
}

resource "openstack_compute_volume_attach_v2" "attach_1" {
  instance_id = openstack_compute_instance_v2.instance_1.id
  volume_id   = openstack_blockstorage_volume_v3.volumes.0.id
}

resource "openstack_compute_volume_attach_v2" "attach_2" {
  instance_id = openstack_compute_instance_v2.instance_1.id
  volume_id   = openstack_blockstorage_volume_v3.volumes.1.id

  depends_on = ["openstack_compute_volume_attach_v2.attach_1"]
}

output "volume_devices" {
  value = [
    openstack_compute_volume_attach_v2.attach_1.device,
    openstack_compute_volume_attach_v2.attach_2.device
  ]
}

Using Multiattach-enabled volumes⁠

For your information

Applicable only to Private Clouds

Multiattach Volumes are dependent upon your OpenStack cloud and not allclouds support multiattach.

resource "openstack_blockstorage_volume_v3" "volume_1" {
  name        = "volume_1"
  size        = 1
  multiattach = true
}

resource "openstack_compute_instance_v2" "instance_1" {
  name            = "instance_1"
  flavor_id       = "1311"
  image_id        = "<image-id>"
  security_groups = ["default"]
}

resource "openstack_compute_instance_v2" "instance_2" {
  name            = "instance_2"
  flavor_id       = "1311"
  image_id        = "<image-id>"
  security_groups = ["default"]
}

resource "openstack_compute_volume_attach_v2" "va_1" {
  instance_id = openstack_compute_instance_v2.instance_1.id
  volume_id   = openstack_blockstorage_volume_v3.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_v3.volume_1.id
  multiattach = true

  depends_on = ["openstack_compute_volume_attach_v2.va_1"]
}

It is recommended to use depends_on for the attachment resourcesto enforce the volume attachments to happen one at a time.

Argument Reference⁠

The following arguments are supported:

• region — (Optional) The region in which to obtain the V2 Compute client.A Compute client is needed to create a volume attachment. If omitted, the region argument of the provider is used. Changing this creates anew volume attachment.

• instance_id — (Required) The ID of the Instance to attach the Volume to.

• volume_id — (Required) The ID of the Volume to attach to an Instance.

• device — (Optional) The device of the volume attachment (ex: /dev/vdc). NOTE: Being able to specify a device is dependent upon the hypervisor inuse. There is a chance that the device specified in Terraform will not bethe same device the hypervisor chose. If this happens, Terraform will wishto update the device upon subsequent application which will cause the volumeto be detached and reattached indefinitely. Please use with caution.

• multiattach — (Optional) Enable attachment of multiattach-capable volumes.Applicable only to Private Clouds.

• vendor_options — (Optional) Map of additional vendor-specific options.Supported options are described below.

The vendor_options block supports:

• ignore_volume_confirmation — (Optional) Boolean to control whetherto ignore volume status confirmation of the attached volume. This can be helpfulto work with some OpenStack clouds which don't have the Block Storage V3 API available.

Attributes Reference⁠

The following attributes are exported:

• region — See Argument Reference above.
• instance_id — See Argument Reference above.
• volume_id — See Argument Reference above.
• device — See Argument Reference above. NOTE: The correctness of thisinformation is dependent upon the hypervisor in use. In some cases, thisshould not be used as an authoritative piece of information.
• multiattach — See Argument Reference above.

Import⁠

Volume Attachments can be imported using the Instance ID and Volume IDseparated by a slash, e.g., by using the Instance ID and Volume IDseparated by a slash.

$ terraform import openstack_compute_volume_attach_v2.va_1 89c60255-9bd6-460c-822a-e2b959ede9d2/45670584-225f-46c3-b33e-6707b589b666