refactor(cni): extract galactic-route as its own CNI chain plugin

[privateip]

Stack (merge bottom to top):

• refactor(cni): split galactic-cni into veth/tap master plugins #303 refactor(cni): split galactic-cni into veth/tap master plugins
• refactor(cni): extract galactic-ipam as a real delegated CNI IPAM plugin #304 refactor(cni): extract galactic-ipam as a real delegated CNI IPAM plugin
• refactor(cni): extract galactic-bgp as its own CNI chain plugin #305 refactor(cni): extract galactic-bgp as its own CNI chain plugin
• refactor(cni): extract galactic-route as its own CNI chain plugin #306 refactor(cni): extract galactic-route as its own CNI chain plugin (this PR)
• docs+fixes(cni): finish the CNI plugin-chain split — docs, containerlab, dead code #307 docs+fixes(cni): finish the CNI plugin-chain split - docs, containerlab, dead code

---

Summary

Fourth branch in the CNI plugin-chain split stack (based on #305). galactic-route is now its own chained CNI plugin — invoked between the master plugin and galactic-bgp per conflist order — instead of termination-route installation inside galactic-cni/galactic-tap-cni. Unlike every other binary in the chain, it has zero Kubernetes dependency: no CRD reads or writes, no namespace.

What moved

internal/cniroute mirrors cniipam/cnibgp's shape: RunPlugin(), PluginConf{VPC, VPCAttachment, Terminations}. parseConf reuses config.CNIConfig for LogFile/LogLevel precedence but never resolves NodeName or Kubeconfig — nothing here talks to the API server.

cmdAdd installs each termination as a VRF route via the existing internal/cni/route package, deriving the host device name from (vpc, vpcAttachment) alone — identical for a veth master's host end and a tap master's tap device, so no interface-kind inference is needed the way galactic-bgp needs it. It requires a non-nil prevResult and passes it through unchanged.

cmdDel is a no-op, matching the pre-split behavior: the old monolithic plugin's own DEL never deleted termination routes either — they're keyed by (vpc, vpcAttachment) and may still be in use by another pod/VM, so cleanup stays with galactic-router's GC controller. cmdCheck is checkTerminationRoutes, moved unchanged. cmdStatus is a trivial always-ready success, matching galactic-ipam's own STATUS.

Rollback scoping

resourceTracker covers only the termination routes this plugin's own ADD actually installed (route-delete only) — rollback never touches a route a failed route.Add call never reached.

Master plugin cleanup

internal/cni/internal/cnitap drop the Terminations field from their own PluginConf (each had its own copy of a Termination type — now lives only in cniroute), the route.Add loop and routesCreated tracker field, and the checkTerminationRoutes call from CHECK.

Verification

• task lint ✅ task build (all 8 binaries) ✅ task test:unit ✅
• internal/cniroute at 62.9% coverage — its first-ever coverage, since internal/cni/route (the package it wraps) had none before this split either. Backfilling that package's own tests is out of scope here.
• task test:e2e not run, same caveat as refactor(cni): split galactic-cni into veth/tap master plugins #303/refactor(cni): extract galactic-ipam as a real delegated CNI IPAM plugin #304/refactor(cni): extract galactic-bgp as its own CNI chain plugin #305.

🤖 Generated with Claude Code

[mattdjenkinson]

Reviewed this one. Overall it's a clean, careful mirror of the sibling packages (cnibgp, cnitap), the resource tracking, rollback, and prevResult handling all follow the established pattern. Two real bugs turned up, though, one of which will break at runtime despite tests and vet passing.

cmd/galactic-route/main.go:67 never sets CNI_NETNS_OVERRIDE, and that will fail ADD/DEL for every VM/tap-mode attachment that has terminations. For a VM/tap-mode attachment, CNI_NETNS is deliberately set to the host's own root netns since there's no per-VM netns to enter, and galactic-route runs natively in that same host netns. Both galactic-cni and galactic-tap-cni handle this today by setting CNI_NETNS_OVERRIDE=true in their own process before calling into the skel library. galactic-route skips that step. The vendored CNI skel dispatcher checks ns.CheckNetNS(cmdArgs.Netns) after the plugin's own Add/Del already ran, sees that the plugin's namespace equals CNI_NETNS, and returns ErrInvalidNetNS unless that override env var is set in its own process, which it isn't here since it's a separately exec'd binary and env doesn't propagate across the chain. So the route actually gets installed correctly, but the CNI runtime sees ADD/DEL reported as failed for every VM/tap-mode attachment with terminations. The doc comment's reasoning, that galactic-route "never enters any network namespace" and so needs neither netns handling nor the override, conflates entering a namespace with the ambient-namespace-equality check the library actually performs.

internal/cniroute/ops_check.go:82 rejects valid on-link routes in CHECK. checkTerminationRoutes runs net.ParseIP(term.Via) and treats a nil result as an error before ever looking at the actual route table. But Termination.Via is omitempty, and assembleRoute in route.go has a dedicated branch for an empty Via that installs a valid on-link route, device-scoped, no gateway. cmdAdd installs this fine. CHECK, though, always fails with "invalid termination gateway """ for any on-link termination even though the route is present and correct. This logic was carried over byte for byte from the pre-split internal/cni/ops_check.go, so the PR relocated an existing bug into galactic-route's CHECK implementation rather than introducing a new one.

Two lower-severity things. docs/cni/configuration.md:100 still documents "terminations" as a field of the master plugin's own JSON config, which this PR removes. An operator following the doc would put terminations inside a galactic-cni or galactic-tap-cni stanza instead of a galactic-route one; the now-slimmer PluginConf silently drops the unknown field on unmarshal, ADD succeeds with no routes installed, and the master's own CHECK no longer checks routes either since that was removed here, so nothing signals that anything's wrong. And internal/cniroute/config.go:205's if conf.PrevResult != nil branch in parseConf is dead code, since PluginConf.PrevResult has json tag "-" and is never populated by json.Unmarshal. Production stays safe because cmdAdd separately validates through parsePrevResult, but this exact pattern is copy-pasted from internal/cni, internal/cnitap, and internal/cnibgp, so it predates this PR and is more of a systemic cleanup item than a regression here.

The netns-override miss is the one I'd block on, it'll break every VM/tap workload with terminations despite the test suite being green. The CHECK bug on on-link routes is worth fixing too since it's a genuine functional bug, just inherited rather than introduced by this PR.