deleting a device from a hardware reservation fails
Closed this issue · 6 comments
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.
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.
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
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.
thanks @enkelprifti98 - I updated the description.
@displague @enkelprifti98 I will take a look.