computer-playbook/roles/svc-bkp-volume-2-local/meta/packages.yml at fix/dev-python/python-upper-bound - computer-playbook - Infinito.Nexus Code Hub

kevinveenbirkenbach/computer-playbook

0 Fork 0

mirror of https://github.com/kevinveenbirkenbach/computer-playbook.git synced 2026-11-08 11:46:35 +00:00

Files

T

kevinveenbirkenbachandClaude Opus 5 197f1df931 feat(ci): let centos nodes deliver btrfs, so the swarm sweep can test snapshots

The distro table pinned centos to ext4, and since the node pool is the
intersection across every distro in a run, the full five-distro sweep always
landed on ext4. btrfs and zfs are what engage the backup snapshot mode, so that
path was never exercised in swarm.

The premise held for a centos system and not for a centos container: Red Hat
dropped btrfs from its own kernel, but a node container runs the host kernel,
and btrfs-progs is merely absent from the base repos - EPEL carries it. Measured
in a centos:stream9 container on this host: mkfs.btrfs, mount, subvolume create,
snapshot -r, and inode 256 at the subvolume root, which is what baudolo checks.

install_packages is the load-bearing part. docker_dataroot.sh ships its own
installer and runs before the ansible package layer, so meta/packages.yml never
reaches it; without the epel fallback there, opening the pool would have let a
centos node be handed btrfs it cannot deliver, decline silently, and leave the
cluster running four btrfs nodes and one ext4 - the very inconsistency the
intersection exists to prevent.

Verified by running the script itself, not extracted parts: it reports
requested=btrfs effective=btrfs on centos.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-01 12:05:15 +02:00

14 lines

193 B

YAML

Raw Permalink Blame History

 ---
 btrfs-tools:
   Archlinux:
     - btrfs-progs
   Debian:
     - btrfs-progs
   RedHat:
     - btrfs-progs
   centos:
     names:
       - btrfs-progs
     repo:
       bootstrap_package: epel-release