Support for Legacy Hardware (x86-64-v2) via configurable Base Image #786
Description
Summary
Current LitmusChaos 3.x images (specifically go-runner) are built on UBI 9 / RHEL 9 base images. These distributions require the x86-64-v2 instruction set (AVX/SSE4.2/POPCNT) in their glibc version (2.34+).
This causes immediate crashes on legacy hardware (e.g., Intel Pentium Gold, Pre-Nehalem CPUs) and generic VM environments (e.g., QEMU/KVM with default CPU models) that do not expose these flags.
Symptom
When running experiments on affected hardware, the runner/experiment pod crashes immediately with:
Fatal glibc error: CPU does not support x86-64-v2
Analysis
- Current Base:
registry.access.redhat.com/ubi9/ubi:9.4 - Requirement: RHEL 9 raises the architectural baseline to x86-64-v2.
- Impact: Users on older nodes or generic virtualization setups cannot run Litmus 3.x components.
Verification
I verified this by rebuilding the runner image using UBI 8 / Rocky Linux 8 (which uses glibc 2.28 / x86-64-v1). The custom image runs successfully on the same hardware where the official image fails.
Proposal
Instead of hardcoding the base image, we should introduce a build argument to allow flexibility.
Current Dockerfile(build/Dockerfile):
FROM [registry.access.redhat.com/ubi9/ubi:9.4](https://registry.access.redhat.com/ubi9/ubi:9.4)Proposed Change:
ARG BASE_IMAGE=registry.access.redhat.com/ubi9/ubi:9.4
FROM ${BASE_IMAGE}
This allows standard builds to remain on UBI 9 (default), while enabling a compat build pipeline for UBI 8 without maintaining separate Dockerfiles.
###References
This issue was discussed with the maintainers in the Kubernetes Slack (Litmus channel): Link to Thread