deleting a device from a hardware reservation fails

[displague]

Deleting a device created from a hardware reservation fails when wait_for_reservation_deprovision = "true" is set.

https://github.com/equinix/terraform-provider-metal/blob/main/metal/resource_metal_device.go#L781

The deployed_hardware_reservation_id should be used rather than the hardware_reservation_id.

As a fall-back, if deployed_hardware_reservation_id is not set, we could consider deleting by hardware_reservation_id so long as it is not set to next-available. If implemented, this would need to be prepared for a 404. One reason not to implement this fall-back behavior is that a reservation consumed outside of this TF config could be incorrectly deleted. Users wanting to clean up a metal_device that lacks deployed_hardware_reservation_id in this case should import the metal_device (consuming the reservation) first, before attempting to delete it.

[displague]

It would be helpful to test device deletion with reservations to prevent this in the future. The resources for doing so in E2E testing would incur costly and parallelization constraints. A mock creation and deletion could be beneficial for testing this behavior.

[displague]

The tell-tale logging sign that this bug is being encountered is:

GET /metal/v1/hardware-reservations/next-available HTTP/1.1

│ Error: Not found

[enkelprifti98]

Just want to clarify here that this issue only happens when wait_for_reservation_deprovision = "true" is set for a metal_device resource. Otherwise deleting reserved instances works fine.

[displague]

thanks @enkelprifti98 - I updated the description.

[t0mk]

@displague @enkelprifti98 I will take a look.

[displague]

Fix released in v3.2.1