Terraform: openstack_compute_instance_v2 block_device not removed.

[vmorris]

Terraform Version

Terraform v0.6.16-dev (507ae65f43d9767dd057f4408b37a2e5cbdf4ceb)

Affected Resource(s)

• openstack_compute_instance_v2
  

  Debug Output

https://gist.github.com/vmorris/6ff907bab20c61a4a9a0de093d82c8dd

Expected Behavior

Boot volume should be removed following a destroy.

Actual Behavior

Boot volume persists following a destroy.

Steps to Reproduce

1. Create new openstack instance with boot from new volume (copied from image)

  block_device  {
    uuid = "${var.image_id_ubuntu}"
    source_type = "image"
    destination_type = "volume"
    boot_index = 0
    volume_size = 10
  }

1. terraform apply
2. Modify block_device to delete on terminate

  block_device  {
    uuid = "${var.image_id_ubuntu}"
    source_type = "image"
    destination_type = "volume"
    boot_index = 0
    volume_size = 10
    delete_on_termination = true
  }

1. terraform apply
2. terraform destroy
   

   Comments

This is a complex use case, just getting it documented for posterity. I am not aware of any option in openstack to alter the on-terminate settings post-deploy but the terraform behaviour tends to imply that one could. Probably terraform should just enforce whatever option was set during the first apply that created the instance.

[jtopjian]

@vmorris This is a good catch.

It should be possible to add a check in the resource's Update function to return an error rather than accepting the change.

[vmorris]

@jtopjian I have to admit, I'm just learning terraform.. I see the update function but not sure what would be required. I'll defer this until later, or if someone can drop a PR, I'd like to review.

Thanks!

[jtopjian]

@vmorris I should be able to tackle this in the next week. I'll keep you updated.

[jtopjian]

@vmorris Sorry for the delay.

Please see #6921. I opted to follow the behavior of the aws_instance resource and trigger a destroy and recreate of the instance when any of the block_device arguments are changed.

Thoughts?

[vmorris]

It's definitely possible to add and remove block devices in openstack without recreating the guest.. I could understand doing this if the block device that's being altered is the boot device, but why recreate otherwise?

[jtopjian]

The name block_device can be confusing. Just to make sure we're on the same page, block_device in the openstack_compute_instance_v2 resource is managed by the os-volumes_boot API extension. Perhaps it should have been called boot_device, but it's possible to create more than one block_device, so maybe ephemeral_device. Anyway, the important thing is that this is entirely separate from attaching and detaching _volumes_.

Unfortunately I'm unable to find good documentation on os-volumes_boot in order to see how an instance can have its boot / ephemeral disks updated after creation. Do you know what commands or API calls are used? If so, I can look at adding support in Gophercloud and then Terraform.

But if there's not a way to alter the boot / ephemeral volumes, then I think it makes sense to just rebuild the entire instance upon any modification to the block_device argument/attribute.

[vmorris]

Hmm, yes thanks for the clarification.
I'm afraid I don't have much information on the matter. The os-volumes_boot API extension is definitely not well documented. From what I gathered today the documentation regressed at some point and there appears to be some gaps now.

[jtopjian]

OK, sounds good. I'm going to proceed with the ForceNew patch. This was actually the originally intended behavior (as can be seen by ForceNew in the block_device attributes), but looks like it didn't take effect when its child arguments were changed. As mentioned, it also matches the AWS EC2 behavior.

If it's discovered that boot/ephemeral devices can be cleanly modified after creation, a subsequent patch can be merged that supports it.

[hashibot[bot]]

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.