You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently generate a random MAC address for guest NICs, whether during a saga or in an explicit call to create a new NIC for an instance. These MAC addresses are guaranteed to be unique, currently within the scope of a VPC, by an index on the network_interface table. If there is a conflict, the entire request fails with a 500-level error. That's a bad experience for the customer, and the MAC address space is not actually that large. (Currently just over 1M addresses, but soon down to just under 1M.)
This issue tracks adding some kind of retry strategy to this, similar to what we do for selecting a random IPv6 subnet for a VPC Subnet. It should noted that this issue may be obviated by choosing an overall different strategy for allocating these addresses. For example, generating a random address, and then doing a linear scan to find the next free address, might be an overall better strategy that could be done entirely in the database.
The text was updated successfully, but these errors were encountered:
We currently generate a random MAC address for guest NICs, whether during a saga or in an explicit call to create a new NIC for an instance. These MAC addresses are guaranteed to be unique, currently within the scope of a VPC, by an index on the
network_interface
table. If there is a conflict, the entire request fails with a 500-level error. That's a bad experience for the customer, and the MAC address space is not actually that large. (Currently just over 1M addresses, but soon down to just under 1M.)This issue tracks adding some kind of retry strategy to this, similar to what we do for selecting a random IPv6 subnet for a VPC Subnet. It should noted that this issue may be obviated by choosing an overall different strategy for allocating these addresses. For example, generating a random address, and then doing a linear scan to find the next free address, might be an overall better strategy that could be done entirely in the database.
The text was updated successfully, but these errors were encountered: