feat: take a VPC identifier from the network - #16
Merged
Conversation
A VPC drew its own random identifier per location, so the two locations of one network were two unrelated networks on the fabric: different VRF names, different Route Targets, no route import between them. The identity that makes them one network is already allocated centrally and carried to each cell, and nothing read it. The VPC now derives its identifier from that identity, through the existing identifier package so the reserved-value guards and the base62 width that keeps a kernel interface name inside fifteen characters still apply. Key changes: - Read the NetworkFabricIdentity for the context's network and encode spec.identity as the VPC identifier - Wait up to five minutes from the VPC's own creation timestamp for an identity that has not propagated yet, since the identifier is immutable and a fallback taken early is permanent - Fall back to the previous random draw past that window, so a network that will never have an identity still gets a working VPC - Report the wait as Ready=False with reason AwaitingFabricIdentity - Watch NetworkFabricIdentity so an arriving identity is taken at once
Falling back to a random identifier when the fabric identity has not arrived is worse than having no VPC. The identifier is immutable, so the fallback is permanent, and the extension server refuses to bind a VRF for any Envoy cluster whose members span more than one VPC. A network whose locations disagree therefore serves no traffic at all, including through healthy members, where a network still waiting recovers the instant its identity lands. Key changes: - Remove the grace period, the poll interval and the random fallback: a VPC with no identity writes no identifier and waits - Rely on the NetworkFabricIdentity watch alone; the informer lists before it watches, so an identity present at startup is seen rather than missed - Delete allocateVPCIdentifier, RandomVPCBase62 and RandomVPC, which the fabric identity leaves with no callers
privateip
approved these changes
Aug 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A network in two locations behaves as two unrelated networks on the fabric: each location's VPC drew its own random identifier, so the two got different VRF names and different Route Targets and never imported each other's routes. The identity that makes them one network is already allocated centrally, once per network, and carried to every cell that needs it, and nothing read it.
A VPC now derives its identifier from that identity, encoded through the existing identifier package so the reserved-value guards and the character budget for kernel interface names still apply. A VPC that already has an identifier keeps it, since renumbering a live one would rename its VRF device and change its routes under running traffic.
A VPC whose identity has not reached the cell yet writes no identifier and reports
Ready=Falsewith reasonAwaitingFabricIdentityuntil it arrives. There is deliberately no fallback: the identifier is immutable, so a random value taken while waiting is permanent, and the extension server refuses to bind a VRF for any Envoy cluster spanning two VPCs, meaning a network whose locations disagree would serve nothing at all rather than recover the moment its identity lands.Test plan
task generate(no diff),task lint,task test:unit. New tests cover a derived identifier, the wait writing nothing, the identity arriving mid-wait being taken, an already-allocated VPC left alone, and the watch enqueuing only the right network's contexts.Related