Publish networks and VPC pod slices to the federation hub - #440
Conversation
A network that spans locations needs one identity on the fabric, but the hub only sees the contexts that name a network, never the network itself, so what allocates the identity cannot tell a deleted network from one required nowhere. The edge also needs each VPC pod's addresses and SRv6 SIDs, which live in a cell that the edge cannot read. Mirror the Network onto the federation hub alongside its contexts, and have each cell publish the VPC EndpointSlices it serves onto the hub under a projection label so the edge can consume them. Run the real VRF sidecar in the dev and e2e Envoy configs, with the token and capability it needs, and make the e2e manager wait for the hub secret it mounts. Key changes: - Replicate Network onto the hub and carry its CRD downstream - Add a cell-side write-back of VPC EndpointSlices to the hub - Replace the placeholder VRF sidecar with the real one - Stop the e2e manager racing the karmada hub secret
ecv
left a comment
There was a problem hiding this comment.
Replicating Network to the hub and the endpoint-slice write-back both follow the shape the interface write-back already set, and the sweep, the copy-never-republished guard, and the owner-reference drop are each explained where they happen and tested.
Two notes, neither blocking:
The comment on federatedEndpointSliceName says the location makes the name "unique rather than merely different", but vpc-<location>-<source> re-splits ambiguously: ("us-east", "1-iad-0") and ("us-east-1", "iad-0") produce one name. Location names are operator-controlled so this is theoretical today, and the long-name path already hashes, so it may just be a matter of hashing unconditionally if you want the comment to hold.
The comment above TestTwoLocationsDoNotCollideOnOneHubName opens on relabel-triggers-removal, but the test only asserts two locations differ, and I don't see a test for the !isVPCPodEndpointSlice withdrawal path that the test-plan checkbox counts as covered. The path reads correct; it's the coverage claim that's ahead of it.
A network that spans locations needs one identity on the fabric, but the hub only ever sees the contexts that name a network, so whatever allocates that identity cannot tell a deleted network from one that is simply required nowhere. This mirrors the network itself onto the federation hub, and has each cell publish the VPC pod endpoint slices it serves onto the hub under a projection label so the edge can consume the addresses and segment identifiers it needs. The dev and e2e Envoy configs now run the real VRF sidecar with the token and capability it needs, and the e2e manager waits for the hub secret it mounts instead of racing it. This is the second of six stacked pull requests splitting the network services prototype, and it depends only on the first.
Test plan