Automated shared Fabric connections
It would be great to have the workflow for creating shared Fabric connections automated similar to how it works on AWS. The proposed workflow is as follows: Creation: User creates Fabric connection in Fabric portal towards Equinix Metal. Automation generates a connection that is pending for approval on the Equinix Metal portal. (Should also be able to do auto approval when using automation tools such as Terraform) User approves the connection on the Equinix Metal portal and can then associate the virtual circuit with their internal VLAN. Deletion: User deletes Connection in Equinix Metal portal which also automatically deletes the connection on the Fabric portal.
Make BGP max_prefix parameter configurable
Currently when user enable BGP for a project there is no way to configure max_prefix parameter. It's set to 10 by default which can be not enough. It would be very good to have an ability to configure that limitation.
On-Demand Dedicated Fabric ports
It would be great to be able to order dedicated Fabric ports on an on-demand basis. This would be useful primarily for users that want to get access to a dedicated port immediately instead of waiting for the ports/cross-connect setup period.
Expose Server Pod and Rack via API and Portal
Allow customers to see which pod and rack they are deployed in and allow them to deploy into specific racks and pods. Anyone using MetalLB and/or ECMP BGP another needs this information to properly balance their traffic.
Dedicated Elastic Server Pools
Dedicated servers that are charged at discounted "dormant" monthly rates but higher "active" hourly rates when in use to support elastic scale needs. These servers can also be provisioned by other users in the Metal Spot Market.
ACL for source IP restriction for SOS Console
Provide feature to limit the source IP addresses allowed to reach the SOS console for reserved instances in a customers given project.
DevCloud for Developer and Small Teams
A version of the Metal platform specifically for developers and small DevTeams. Flat pricing and access to gear without barriers. Lowered SLA's and limited configurations.
Support Consolidated Billing
Receive consolidated invoicing across Projects and Organizations
The current RescueOS option re-uses OSIE's custom Alpine kernel/initramfs. This is OK, but has always had some rough edges. What if the instance is a Custom iPXE that Alpine can't really mess with (NixOS, ZFS, *BSD, ...)? It would be nice to extend the extend the Rescue system to boot from boot.netboot.xyz or a BYORescue. Netboot has all sorts of live environments that may have better tools than our Alpine.