feat: derive VPC identifier from the network's fabric identity - #11
Closed
scotwells wants to merge 1 commit into
Closed
feat: derive VPC identifier from the network's fabric identity#11scotwells wants to merge 1 commit into
scotwells wants to merge 1 commit into
Conversation
Each cell runs its own copy of the NetworkContext reconciler, and each one drew a random VPC identifier checked only against the VPCs in its own cluster. One network spanning two locations therefore ended up with two unrelated identifiers, which galactic reads as two different networks: the edge VRF device is named from the VPC alone, and the Route Target is derived from it, so neither location imports or exports the other's routes. When the network carries an identity allocated for it, the VPC identifier is now rendered from that value, so every cell reaches the same one. A network without one keeps drawing a random identifier exactly as before, and a VPC that already holds an identifier is never renumbered. Key changes: - Add identifier.VPCBase62 to render a known 48-bit value, alongside the existing random draw - Read the allocated identity from NetworkContext spec and derive the identifier from it when present - Fall back to the existing random allocation when no identity is present
privateip
approved these changes
Aug 27, 2026
This was referenced Aug 27, 2026
Collaborator
Author
|
Superseded by #12, now merged. That change allocates the identity in this repo rather than reading a field projected from network-services-operator, so the approach here no longer applies. The problem statement and review history stay on the record. |
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 that spans two locations ends up with two unrelated VPC identifiers, because each cell invents one at random and checks it only against its own cluster. Galactic reads that as two different networks: it names the edge VRF device from the identifier and derives the Route Target from it, so the two locations neither share a device nor exchange routes.
This is the consumer half of that fix. It derives the identifier from a single identity allocated once for the network, so every cell reaches the same value. A network with no identity keeps drawing a random one, and a VPC that already holds an identifier is never renumbered.
Superseded by #12, which allocates the identity in this repo rather than reading a field projected from network-services-operator. Kept open for the problem statement and review history.
Related: datum-cloud/enhancements#870