test: check a network reaches the cell serving it - #229
Merged
Conversation
…tion A NetworkContext written on the Karmada hub in a project's downstream namespace must arrive on the POP cell for that location carrying the fields the cell acts on, and must go away again when it is withdrawn. infra keeps a hand-maintained fork of NSO's propagation policy rather than consuming NSO's copy, so a selector NSO adds on its side can be inert on ours with nothing to say so: the policy looks right, the CRD exists, and the object reaches nowhere. This suite is the regression guard for that class of silent failure. The environment applies NSO's real propagation policy from the module cache, so the selectors under test are the ones production runs. Delivery is asserted on spec.ipFamilies and spec.mtu by value rather than on the object's mere existence, because those are what a cell's claim reconciler reads; a copy without them is indistinguishable downstream from one that never arrived. The companion assertion that hub status does not cross is what keeps that honest, and is why both fields have to live in spec. The context is created directly on the hub rather than reconciled from a NetworkBinding, and claim readiness is left alone: no NSO controller-manager runs here, and that path belongs to NSO's own e2e against a real IPAM. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
scotwells
marked this pull request as ready for review
August 14, 2026 16:38
scotwells
enabled auto-merge
August 14, 2026 16:38
ecv
approved these changes
Aug 14, 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 workload gets its address from the network layer where it runs. That only works if the network's presence reaches the cell — and until now nothing checked that it did.
Why this is worth a test of its own
This path failed silently once already. The network layer added the rule that carries a network's presence to a location, but the copy of that configuration we actually deploy is maintained by hand, so the rule never reached anywhere. Everything looked right: the resource existed, the configuration named it, and it arrived nowhere.
This is the check that catches that shape of failure — where nothing errors and nothing arrives.
What it proves
A network's presence, created centrally, reaches the cell serving that location carrying the details a workload needs — the address families it can use and its packet size. It also proves those details survive the trip, and that removing the network withdraws it from the cell rather than leaving it serving addresses on a network that is no longer there.
What it does not cover
Handing out the addresses themselves. That happens in the network layer's own environment, against a real address allocator, and is tested there.
Related