Skip to content

Add composefs backend#61

Merged
alicefr merged 2 commits into
mainfrom
composefs-backend
Jun 11, 2026
Merged

Add composefs backend#61
alicefr merged 2 commits into
mainfrom
composefs-backend

Conversation

@alicefr

@alicefr alicefr commented Jun 11, 2026

Copy link
Copy Markdown
Collaborator

Fixes: #9

Summary by Sourcery

Add support for building and publishing Fedora node disk images using a composefs backend and align CNI paths with /var/lib/cni/bin across the system.

New Features:

  • Introduce a composefs-backed node disk image variant and associated Make targets.
  • Extend the CI workflow to build and push composefs disk images for Fedora node images.

Enhancements:

  • Align CRI-O and Calico configuration to use /var/lib/cni/bin and /etc/cni/net.d for CNI plugins and configs.
  • Make the ostree-state-overlay@opt service enabling step tolerant of failure during node initialization.
  • Document new Makefile targets and BCVK extra arguments in the Fedora node image build help output.

CI:

  • Update the node image build GitHub Actions workflow to build and push composefs disk image variants.

alicefr added 2 commits June 11, 2026 14:45
The composefs backend mounts root as read-only, so CRI-O fails to
mkdir /opt/cni. Move Calico and CRI-O CNI paths to /var/lib/cni/bin
which is writable on both ostree and composefs backends.

Assisted-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Alice Frosi <afrosi@redhat.com>
Wire bcvk --composefs-backend through the build system and CI so both
ostree and composefs disk images are built and pushed to the registry.

Assisted-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Alice Frosi <afrosi@redhat.com>
@sourcery-ai

sourcery-ai Bot commented Jun 11, 2026

Copy link
Copy Markdown

Reviewer's Guide

Adds support for building and publishing a composefs-backed node disk image for Fedora node images, while standardizing CNI paths from /opt/cni to /var/lib/cni and /etc/cni/net.d, and making cloud-init/user-data and cluster manifests consistent with the new layout.

Sequence diagram for composefs-backed disk image build and push

sequenceDiagram
    participant GitHubActions
    participant Makefile
    participant bcvk
    participant Registry

    GitHubActions->>Makefile: make build-disk-image-composefs BOOTC_IMAGE BOOTC_DIGEST
    Makefile->>Makefile: build-disk-image BCVK_EXTRA_ARGS=--composefs-backend NODE_IMAGE=NODE_IMAGE_COMPOSEFS
    Makefile->>bcvk: bcvk to-disk --composefs-backend
    bcvk-->>Makefile: composefs qcow2 image
    GitHubActions->>Makefile: make print-node-image-composefs
    Makefile-->>GitHubActions: NODE_IMAGE_COMPOSEFS
    GitHubActions->>Registry: podman tag NODE_IMAGE_COMPOSEFS :TAG-disk-composefs
    GitHubActions->>Registry: podman push :TAG-disk-composefs
    GitHubActions->>Registry: podman tag NODE_IMAGE_COMPOSEFS :latest-disk-composefs
    GitHubActions->>Registry: podman push :latest-disk-composefs
Loading

File-Level Changes

Change Details Files
Add composefs-backed disk image build and push pipeline for Fedora node images.
  • Extend Fedora node Makefile with BCVK_EXTRA_ARGS variable, composefs-specific NODE_IMAGE tag, and build-disk-image-composefs target that wraps build-disk-image with --composefs-backend.
  • Add print-node-image-composefs helper to output the composefs disk image reference.
  • Update GitHub Actions build-node-image workflow to build a composefs disk image after the standard disk image, reusing BOOTC_DIGEST/PUSH_DEST if available, and to tag/push composefs images with -disk-composefs suffix and latest-disk-composefs alias.
node-images/fedora/Makefile
.github/workflows/build-node-image.yaml
Standardize CNI binary and config paths to /var/lib/cni/bin and /etc/cni/net.d across node image, CRI-O config, cloud-init, and Calico manifests.
  • Remove /opt/cni/bin from crio.network.plugin_dirs in cloud-init user-data, ensure /var/lib/cni/bin directory is created at boot, and make enabling ostree-state-overlay@opt.service non-fatal by ignoring failures.
  • Patch CRI-O config inside the Fedora node image to rewrite CNI bin dir from /opt/cni/bin to /var/lib/cni/bin and net dir from /opt/cni/net.d to /etc/cni/net.d.
  • Align Calico DaemonSet hostPath for the CNI bin dir with /var/lib/cni/bin to match the new CRI-O and node layout.
  • Update cluster initialization logging to reference /var/lib/cni/bin as the CNI plugins installation path.
internal/node/templates/user-data.yaml.tmpl
node-images/fedora/Containerfile
internal/cluster/calico.yaml
internal/cluster/init.go

Assessment against linked issues

Issue Objective Addressed Explanation
#9 Add support in the build system to produce a composefs backend disk image in addition to the existing ostree backend disk image.
#9 Ensure the CI/workflow builds and pushes both ostree and composefs backend disk images to the registry so both variants are available for developers and tests.

Possibly linked issues


Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've found 1 security issue, 1 other issue, and left some high level feedback:

Security issues:

  • Container should not be privileged (link)

General comments:

  • The clean target in node-images/fedora/Makefile only removes $(BOOTC_IMAGE) and $(NODE_IMAGE) and should be updated to also remove $(NODE_IMAGE_COMPOSEFS) to avoid leaving composefs images behind.
  • The GitHub Actions workflow now has nearly duplicated logic for pushing disk images (standard vs composefs); consider extracting the common tagging/pushing commands into a shared snippet or composite action to reduce drift between the two paths.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- The `clean` target in `node-images/fedora/Makefile` only removes `$(BOOTC_IMAGE)` and `$(NODE_IMAGE)` and should be updated to also remove `$(NODE_IMAGE_COMPOSEFS)` to avoid leaving composefs images behind.
- The GitHub Actions workflow now has nearly duplicated logic for pushing disk images (standard vs composefs); consider extracting the common tagging/pushing commands into a shared snippet or composite action to reduce drift between the two paths.

## Individual Comments

### Comment 1
<location path="internal/node/templates/user-data.yaml.tmpl" line_range="82" />
<code_context>
   - systemctl daemon-reload
   - systemctl enable --now var-mnt-cluster_images.mount
-  - systemctl enable --now ostree-state-overlay@opt.service
+  - systemctl enable --now ostree-state-overlay@opt.service || true
   - systemctl enable --now qemu-guest-agent
   - nmcli connection modify "cloud-init enp2s0" ipv4.dns-search "~{{.ClusterDomain}} {{.ClusterDomain}}"
</code_context>
<issue_to_address>
**issue (bug_risk):** Silencing `systemctl` failures may hide real issues; consider at least logging failures explicitly

Using `|| true` here means any failure from `systemctl enable --now ostree-state-overlay@opt.service` (e.g., missing or misconfigured unit) will be silently ignored, making provisioning issues hard to detect. If this service is optional, guard the call with an explicit check (e.g., verifying the unit file exists or checking `systemctl list-unit-files`) and/or log a clear message when `systemctl` fails so it’s obvious when the overlay is not active.
</issue_to_address>

### Comment 2
<location path="internal/cluster/calico.yaml" line_range="5026-5032" />
<code_context>

</code_context>
<issue_to_address>
**security (CKV_K8S_16):** Container should not be privileged

Privileged containers are containers that have all of the root capabilities of a host machine, allowing access to resources that are not accessible in ordinary containers.
Common uses of privileged containers include: running a Docker daemon inside a Docker container, running a container with direct hardware access, and automating CI/CD tasks in the open-source automation server Jenkins.
Running a container with a privileged flag allows users to have critical access to the host's resources.
If a privileged container is compromised, it does not necessarily entail remote code execution, but it implies that an attacker will be able to run full host root with all of the available capabilities, including  CAP_SYS_ADMIN.

<details>
<summary>Fix</summary>

*Kubernetes*


* *Resource:* Container
* *Arguments:* privileged (Optional)

If true, processes in the privileged containers are essentially equivalent to root on the host.
Default to false.


```yaml
apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
    securityContext:
-      privileged: true
```

</details>

*Source: checkov*
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

- systemctl daemon-reload
- systemctl enable --now var-mnt-cluster_images.mount
- systemctl enable --now ostree-state-overlay@opt.service
- systemctl enable --now ostree-state-overlay@opt.service || true

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue (bug_risk): Silencing systemctl failures may hide real issues; consider at least logging failures explicitly

Using || true here means any failure from systemctl enable --now ostree-state-overlay@opt.service (e.g., missing or misconfigured unit) will be silently ignored, making provisioning issues hard to detect. If this service is optional, guard the call with an explicit check (e.g., verifying the unit file exists or checking systemctl list-unit-files) and/or log a clear message when systemctl fails so it’s obvious when the overlay is not active.

Comment on lines 5026 to 5032
# Used to install CNI.
- name: cni-bin-dir
hostPath:
path: /opt/cni/bin
path: /var/lib/cni/bin
- name: cni-net-dir
hostPath:
path: /etc/cni/net.d

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

security (CKV_K8S_16): Container should not be privileged

Privileged containers are containers that have all of the root capabilities of a host machine, allowing access to resources that are not accessible in ordinary containers.
Common uses of privileged containers include: running a Docker daemon inside a Docker container, running a container with direct hardware access, and automating CI/CD tasks in the open-source automation server Jenkins.
Running a container with a privileged flag allows users to have critical access to the host's resources.
If a privileged container is compromised, it does not necessarily entail remote code execution, but it implies that an attacker will be able to run full host root with all of the available capabilities, including CAP_SYS_ADMIN.

Fix

Kubernetes

  • Resource: Container
  • Arguments: privileged (Optional)

If true, processes in the privileged containers are essentially equivalent to root on the host.
Default to false.

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
    securityContext:
-      privileged: true

Source: checkov

@alicefr alicefr merged commit d30220c into main Jun 11, 2026
6 of 9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Build both ostree and composefs backend disks

1 participant