Closed displague closed 2 years ago
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.
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 thehardware_reservation_id
.As a fall-back, if
deployed_hardware_reservation_id
is not set, we could consider deleting byhardware_reservation_id
so long as it is not set tonext-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 ametal_device
that lacksdeployed_hardware_reservation_id
in this case should import the metal_device (consuming the reservation) first, before attempting to delete it.