18
Improved Use of Reserved Hardware
under review
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.
Log In
Activity Feed
Sort by
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 👍