docs+refactor(cni): fix stale package doc, promote hostconf/crdnames/nadpatch - #315
Open
privateip wants to merge 1 commit into
Open
Conversation
privateip
force-pushed
the
refactor/cni-chain-4-installer-docs
branch
from
August 8, 2026 19:04
725ef87 to
c690b5b
Compare
…nadpatch Follow-up to mattdjenkinson's review on #303 (2 of 5 points; the other 3 are handled separately — 1 already resolved upstream in this stack, 1 is now moot, 1 is the dedup fix in a stacked follow-up branch). internal/cni/doc.go still described the package as creating "a veth or tap interface" and listed a tap subpackage as its own, both stale since step 0 of this stack made galactic-cni veth-only and moved tap to its own binary (galactic-tap-cni/internal/cnitap). Rewrote the package doc to describe what internal/cni actually does now (VRF + veth pair + NAD patch only — IPAM, termination routes, and BGP publish are galactic- ipam's/galactic-route's/galactic-bgp's own concerns, chained after this plugin) and to explain why internal/cni/ipam, internal/cni/route, and internal/cni/tap are still physically nested here despite no longer being used by this package itself. Promoted hostconf, crdnames, and nadpatch from internal/cni/* to top-level internal/*, matching the placement cnibgp/cniipam/cnitap/ cniroute already have. All four groups do the same cross-binary- sharing job; leaving hostconf/crdnames/nadpatch nested under internal/cni made it look like internal/cnitap (and cnibgp/cniroute) were reaching into cni's own internals, which is exactly what extracting them in the first place was meant to avoid. Package names are unchanged — every call site is a mechanical import-path update (15 files). internal/cni/ipam, internal/cni/route, and internal/cni/tap are a different category (kernel-primitive packages, like veth) and were not part of this review point, so they're untouched. task lint / task build / task test:unit all clean.
privateip
force-pushed
the
fix/cni-review-followups-doc-placement
branch
from
August 8, 2026 19:06
5f1d26b to
6cd671f
Compare
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
1 participant
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.
Follow-up to mattdjenkinson's review on #303 — 2 of the review's 5 points. The other 3 are handled separately:
isTapMode()/CNI_NETNS_OVERRIDEdead-code point was already resolved upstream in this stack (725ef87, this branch's own parent).tracker.k8sguard point is now moot — the BGP publish call it was about no longer lives inops_add.goat all (moved to its owngalactic-bgpchain plugin ine33092c).internal/cnitapvsinternal/cniduplication point is a separate, larger follow-up: #(fix/cni-review-followups-dedup), stacked on top of this branch.I'll leave a comment on #303 summarizing all 5.
This PR
internal/cni/doc.gostaleness. The package doc still said ADD creates "a veth or tap interface" and listedtapas one of this package's subpackages — both stale since step 0 of this stack madegalactic-cniveth-only and moved tap togalactic-tap-cni/internal/cnitap. Rewrote the doc to describe whatinternal/cniactually does now (VRF + veth pair + NAD patch only) and to explain whyinternal/cni/ipam,internal/cni/route, andinternal/cni/tapare still physically nested there despite no longer being used by this package itself.Package placement inconsistency.
hostconf,crdnames, andnadpatchwere nested underinternal/cni/*whilecnibgp/cniipam/cnitap/cniroute— doing the same cross-binary-sharing job — got promoted to top-levelinternal/*. That made it look likeinternal/cnitap(andcnibgp/cniroute) were reaching intocni's own internals, which is exactly what extracting them in the first place was meant to avoid. Promoted all three tointernal/hostconf,internal/crdnames,internal/nadpatch. Package names are unchanged — every call site is a mechanical import-path update (15 files) plus two doc references (ARCHITECTURE.md, a comment ininternal/cniroute/config.go).internal/cni/ipam,internal/cni/route, andinternal/cni/tapare a different category (kernel-primitive packages, likeveth) and weren't part of this review point, so they're untouched.Verification
task lint✅task build✅ (all 8 binaries)go vet ./...✅task test:unit✅ (33/33 packages passing)task test:e2enot run (same caveat as every step in this stack — needs a Kind cluster bring-up not attempted here)🤖 Generated with Claude Code