build(nix): Wrap vtysh so it loads the gateway's commands - #1704
build(nix): Wrap vtysh so it loads the gateway's commands#1704daniel-noland wants to merge 1 commit into
Conversation
📝 WalkthroughWalkthroughChangesFRR packaging now accepts optional vtysh extension libraries. The dataplane overlay enables extension loading, while the host build uses upstream FRR without extensions. Enabled builds wrap FRR vtysh extension support
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
Wrap vtysh in our FRR fork so every invocation loads the Hedgehog extension, including sessions started through kubectl exec and docker exec. Set up the wrapper after nuke-refs and use the plugin's runtime image path to avoid a dependency cycle. Upstream FRR remains unchanged because it does not support -X. Also remove the obsolete extension patch reference; the loader already lives in the fork. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Daniel Noland <daniel@githedgehog.com>
09025de to
c1f8579
Compare
There was a problem hiding this comment.
Pull request overview
This PR updates the Nix packaging for FRR to ensure vtysh automatically loads the gateway’s custom command extension (libvtysh_hedgehog.so) when building the dataplane FRR fork, avoiding reliance on shell aliases that don’t apply to kubectl exec / docker exec.
Changes:
- Add optional
makeWrappersupport and apostFixupwrapper that injects-X <extension>flags intovtyshwhenvtysh-extensions = true. - Introduce configurable
vtysh-extension-libs(defaulting to/lib/libvtysh_hedgehog.so) as image-path targets to avoid Nix-store dependency cycles. - Adjust the FRR overlay to enable the wrapper only for
frr.dataplane(fork), leavingfrr.host(upstream) unwrapped.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| nix/pkgs/frr/default.nix | Adds optional wrapping of vtysh in postFixup to auto-load configured extension libraries. |
| nix/overlays/frr.nix | Enables the wrapper only for the dataplane FRR fork and keeps upstream host FRR unchanged. |
| # Whether this FRR source carries our vtysh extension loader, i.e. whether | ||
| # its vtysh understands `-X <path-to-extension.so>`. Our fork (`frr-dp`) | ||
| # does; upstream (`frr`, used for the host image) does not, and passing it | ||
| # `-X` would only earn us an "invalid option". When set, the install phase | ||
| # wraps `vtysh` so that it loads `vtysh-extension-libs` without being asked. |
mvachhar
left a comment
There was a problem hiding this comment.
Do we care about the AI nitpick about the install vs. post-install in the comment? If we care fix and then merge, otherwise just merge.
Addresses the goal of issue #1674, by a different route than the one the issue proposes.
Our FRR fork teaches vtysh a
-X <path>flag that dlopen()s an extension, and the commands the gateway adds live in one such extension,libvtysh_hedgehog.so. Nobody passes the flag today, so those commands are absent unless whoever is typing knows to ask.Why a wrapper rather than an alias
An alias only reaches callers that read a shell rc, and the two that matter most do not:
kubectl execanddocker execstart no login shell. The shortcut would be missing in exactly the session someone opened to work out what a running gateway is doing.