container: merge grout and FRR into a single image#616
Conversation
|
Caution Review failedPull request was closed or merged during review Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThis PR consolidates the container build into a single Containerfile, updates the publish workflow to extract grout and frr RPM VERSIONs and label the grout image with grout_version and frr_version, and replaces prior releaser steps with explicit gh release commands. The Containerfile now stages all *.rpm files, adds /usr/bin/frr as a wrapper, and changes the final image ENTRYPOINT to /usr/libexec/catatonit/catatonit -- with CMD /usr/bin/grout. It also adds docs/quadlets with podman/systemd quadlets and helper scripts for device bind/unbind and a metrics proxy. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/publish.yml:
- Line 48: The workflow step is defined as id: frr-version but subsequent
references use steps.version, causing missing outputs; rename the step id from
frr-version to version (update the step with id: frr-version -> id: version) so
that the existing references to steps.version and outputs (used for image
labels/publish) resolve correctly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 1d5bff72-55c8-4be4-be80-45f5c96bc415
📒 Files selected for processing (3)
.github/workflows/publish.ymlContainerfileContainerfile.grout
💤 Files with no reviewable changes (1)
- Containerfile.grout
|
@zeeke what do you think? |
I'm ok with these changes. I'm not sure where and how the images are used right now. which currently consume released RPMs files |
There was a problem hiding this comment.
♻️ Duplicate comments (1)
.github/workflows/publish.yml (1)
48-48:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winFix broken step output reference used by Docker labels.
Line 48 defines
id: frr-version, but Lines 66-67 read fromsteps.version.outputs.*. That key is undefined, so metadata label values cannot resolve correctly.Suggested fix
- id: frr-version + id: versionAlso applies to: 66-67
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/publish.yml at line 48, The workflow defines the step id as frr-version but later reads steps.version.outputs.*, which is undefined; update the references so they match — either rename the step id from frr-version to version (targeting the step that generates outputs) or change all usages of steps.version.outputs.* to steps.frr-version.outputs.* (including the Docker labels usage), ensuring the id in the producing step (frr-version) and the consuming references are identical.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Duplicate comments:
In @.github/workflows/publish.yml:
- Line 48: The workflow defines the step id as frr-version but later reads
steps.version.outputs.*, which is undefined; update the references so they match
— either rename the step id from frr-version to version (targeting the step that
generates outputs) or change all usages of steps.version.outputs.* to
steps.frr-version.outputs.* (including the Docker labels usage), ensuring the id
in the producing step (frr-version) and the consuming references are identical.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 253d20ac-5dc5-4f34-bf52-f060c397e877
📒 Files selected for processing (3)
.github/workflows/publish.ymlContainerfileContainerfile.grout
💤 Files with no reviewable changes (1)
- Containerfile.grout
The executable is at /usr/libexec/catatonit/catatonit. Fixes: d1a19cf ("packaging: use catatonit instead of tini") Signed-off-by: Robin Jarry <rjarry@redhat.com>
The FRR dplane_grout plugin is tightly coupled with grout. Delivering them as separate container images can cause API/ABI mismatches between the plugin and the daemon. Merge everything into a single Containerfile to ensure both are always aligned. The default entrypoint starts grout. A /usr/bin/frr helper script is provided to start FRR daemons separately. For example: podman run -d --name grout --privileged quay.io/grout/grout podman exec grout frr Signed-off-by: Robin Jarry <rjarry@redhat.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/publish.yml:
- Line 68: The workflow is using a mutable tag for the GitHub Action ("uses:
docker/build-push-action@v7"); replace that with a pinned immutable reference by
updating the "uses" entry for docker/build-push-action to the action's
repository at a specific commit SHA (e.g.,
docker/build-push-action@<commit-sha>) so the workflow references a fixed
commit; locate the line containing "docker/build-push-action@v7" and swap the
tag for the chosen commit SHA from the upstream repo's releases/commits.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 9c62ee65-ac3b-4989-951b-9636294ed625
📒 Files selected for processing (3)
.github/workflows/publish.ymlContainerfileContainerfile.grout
💤 Files with no reviewable changes (1)
- Containerfile.grout
| labels: | | ||
| frr_version=${{steps.version.outputs.frr}} | ||
| grout_version=${{steps.version.outputs.grout}} | ||
| - uses: docker/build-push-action@v7 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# List workflow actions not pinned to a 40-char commit SHA
rg -nP '^\s*-\s+uses:\s+\S+@(?![0-9a-f]{40}\b)\S+' .github/workflowsRepository: DPDK/grout
Length of output: 1692
Pin this GitHub Action to a commit SHA.
The action uses a mutable tag (@v7), which can be retargeted by the upstream repository and exposes the workflow to supply-chain risk.
🧰 Tools
🪛 zizmor (1.25.2)
[error] 68-68: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/publish.yml at line 68, The workflow is using a mutable
tag for the GitHub Action ("uses: docker/build-push-action@v7"); replace that
with a pinned immutable reference by updating the "uses" entry for
docker/build-push-action to the action's repository at a specific commit SHA
(e.g., docker/build-push-action@<commit-sha>) so the workflow references a fixed
commit; locate the line containing "docker/build-push-action@v7" and swap the
tag for the chosen commit SHA from the upstream repo's releases/commits.
There was a problem hiding this comment.
isn't this the case for all third party actions?
There was a problem hiding this comment.
@rjarry, yes, you're correct — the same concern applies to all third-party actions in the workflow (actions/checkout@v6, actions/download-artifact@v8, docker/setup-qemu-action@v4, docker/setup-buildx-action@v4, docker/login-action@v4, docker/metadata-action@v6). The static analysis tool flagged only the line in the diff, but the supply-chain risk is consistent across the entire file and is pre-existing rather than introduced by this PR.
Would you like me to open a separate issue to track pinning all workflow actions to commit SHAs?
pyTooling/Actions/releaser is deprecated. Replace it with direct gh CLI calls. On pushes to main, recreate a rolling "edge" pre-release. On version tags, create a proper release with auto-generated notes. Include container image usage instructions in the release notes. Signed-off-by: Robin Jarry <rjarry@redhat.com>
Provide example systemd/podman quadlet files to run grout and FRR as containers. The grout container runs in privileged mode with no network namespace, and FRR joins it via NetworkNS to share interfaces. A third container runs socat to expose grout's openmetrics unix socket over TCP port 9111 in its own network namespace. All three containers share /run via an anonymous volume on the grout container. Signed-off-by: Robin Jarry <rjarry@redhat.com>
The FRR dplane_grout plugin is tightly coupled with grout. Delivering them as separate container images can cause API/ABI mismatches between the plugin and the daemon. Merge everything into a single Containerfile to ensure both are always aligned.
The default entrypoint starts grout. A /usr/bin/frr helper script is provided to start FRR daemons separately. For example:
Container image consolidation
Merged grout and FRR builds into a single Containerfile; removed the FRR-specific build and Containerfile.grout to prevent API/ABI mismatches between the dplane_grout plugin and the FRR daemon by keeping both components built and versioned in one image.
CI / release workflow changes (.github/workflows/publish.yml)
versionstep that queries RPM artifacts and exports grout and frr VERSIONs as outputs.grout_versionandfrr_versionlabels fromsteps.version.outputs.meta-frrand Containerfile.frr build; docker/build-push-action invoked once using Containerfile to build/push linux/amd64 and linux/arm64 images for quay.io/${{ vars.REGISTRY_NAMESPACE || 'grout' }}/grout.gh releasesteps—an “Update edge pre-release” (delete/recreate edge pre-release with container run instructions) and a “Create release” step for version tags that creates releases including container run instructions.Containerfile changes (multi-stage build → unified image)
Deleted file
Deployment examples and systemd/podman unit helpers (docs/quadlets)
grcliagainst /etc/grout.init.groutnetwork namespace and bring up loopback.Runtime impact / usage