Improved Use of Reserved Hardware
future consideration
E
Enkel Prifti
The Metal API currently has a hardware_reservation_id field (https://metal.equinix.com/developers/api/hardwarereservations/) which accepts either the Reservation UUID or a next-available option, which chooses any reservation that is provisionable and matches the instance type/location criteria. There are limitations with this approach when using 3rd party provisioning tools, such as Terraform (e.g. not having enough reserved hardware for a request or the requirement of having to redeploy the entire cluster when converting from on-demand -> reserved).
Two improvements would help the use of the Reserved Hardware capability:
- Allow a new string such as "hardware_reservation_id" : "prefer" so that the API will use hardware reservations that match the criteria and then fulfill the rest of the capacity requirement with on-demand instances. This would be used by every user regardless of whether the instance is on-demand or reserved which would allow for seamless instance conversions from on-demand to reserved and vice-versa.
- Allow hardware reservations to be used Organization wide (perhaps from a "Default" project) instead of having to move the hardware between Projects before uses it. This would allow any project to access a pool of hardware reservations instead of tying reservations to specific projects. We can offer the ability to lock reservations to specific projects as it is done today.
S
Sal Carrasco
future consideration
Sal Carrasco
under review
Chris Turra
this would be really useful for us as well! throwing my vote into the mix.
Sal Carrasco
planned / on deck
Marques Johansson
Merged in a post:
Enhance hardware_reservation_id Logic
Damian Sieczkowski
Today, if you pass next-available or a ${reservation-id} to hardware_reservation_id in POST /projects/{id}/devices, it will fail if there isn't a reservation available. This creates scaling issues when using Terraform. It would be great if we can support something like hardware_reservation_id = next-available-or-on-demand.
Specifically, in the case of Terraform, if a user wants to provision 10 servers, but only has 5 reservations remaining, they should be able to do this in a single equinix_metal_device resource. Today, that's not possible because if a hardware_reservation_id is passed to the API, and the requested reservation-id isn't available, or next-available doesn't return an available reservation, the API won't provision a device. The API shouldn't enforce a strict requirement that a POST to /projects/{id}/devices specify a reserved server or on-demand.
This has implications beyond Terraform; anyone making a call to POST /projects/{id}/devices may need to scale beyond their reserved capacity, but make sure they are using all their reserved capacity. Supporting an option like "next-available-or-on-demand."
M
Miles Thomas
under review
E
Enkel Prifti
another issue related to this is when converting on-demand instances to reserved will cause terraform to re-deploy everything under the existing terraform resource.
Damian Sieczkowski
This is cool, I haven't seen folks request this but I like it 👍