ROCm pytorch: reduce peak disk during uv/torch install in Dockerfile

[jiridanek]

Parent: #2491

Idea

ROCm pytorch images are the largest matrix builds. Peak disk during uv pip install + de-vendor-torch.sh may hit 100% before the build finishes — pruning after success does not help.

Approach

In jupyter/rocm/pytorch/ubi9-python-3.12/Dockerfile.konflux.rocm and runtimes/rocm-pytorch/ubi9-python-3.12/Dockerfile.konflux.rocm:

• Delete pip/uv cache in the same RUN layer as install (rm -rf /root/.cache/uv)
• Remove torch vendored ROCm blobs before de-vendor-torch.sh symlinks system libs (script already rm -rfs rocblas/hipblaslt dirs — ensure ordering minimizes peak usage)
• Strip unnecessary artifacts where safe (__pycache__, static .a in site-packages if not needed at runtime)

Compare with green rocm-jupyter-tensorflow Dockerfile for patterns that keep peak disk lower.

Out of scope

• Post-build podman system prune (see [rhoai-2.25] RHAIENG-6036: prune podman storage around ROCm matrix builds #2489 / parent rhoai-2.25: backport main CI disk strategy (#3965/#3967) to fix ROCm matrix ENOSPC #2491)
• Changing torch/rocm package versions

Acceptance criteria

• make rocm-jupyter-pytorch-ubi9-python-3.12 completes on GHA amd64 without ENOSPC
• make rocm-runtime-pytorch-ubi9-python-3.12 same
• Image tests and check-payload still pass on the built image

[jiridanek]

Update

Peak-disk ENOSPC for ROCm pytorch on rhoai-2.25 GHA was fixed in merged #2647 (same-RUN de-vendor-torch.sh + gated free-up). Push builds for jupyter + runtime ROCm pytorch went green at ~58–59% disk peak (was 100%).

@coderabbitai — acceptance criteria on this issue look met for GHA amd64; remaining “fuller main layering” is tracked in #2650 rather than more Dockerfile peak-trim here.

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

repo="red-hat-data-services/notebooks"

printf '%s\n' '--- Issue `#2493` ---'
gh issue view 2493 --repo "$repo" --json number,title,state,body,url,comments \
  --jq '{number,title,state,url,body,comments:[.comments[]|{author:.author.login,body:.body,url:.url}]}'

printf '%s\n' '--- PR `#2647` ---'
gh pr view 2647 --repo "$repo" --json number,title,state,mergedAt,url,body \
  --jq '{number,title,state,mergedAt,url,body}'

printf '%s\n' '--- Issue `#2650` ---'
gh issue view 2650 --repo "$repo" --json number,title,state,url,body \
  --jq '{number,title,state,url,body}'

Length of output: 10855

---

@jiridanek, agreed that the peak-disk objective and both GHA amd64 build criteria appear satisfied: #2647 is merged and the reported ROCm Jupyter/runtime builds completed at ~58–59% peak disk rather than hitting ENOSPC.

The broader install/layering alignment is correctly scoped to #2650. One small closure check remains: #2493 also requires that image tests and check-payload pass on the built images; that result was not explicit in the retrieved issue/PR details. Once confirmed, #2493 can be closed confidently.

---

✏️ Learnings added

Learnt from: jiridanek
URL: https://github.com/red-hat-data-services/notebooks/issues/2493

Timestamp: 2026-07-30T14:58:56.137Z
Learning: For `rhoai-2.25` ROCm PyTorch images in the `red-hat-data-services/notebooks` repository, PR `#2647` moved `de-vendor-torch.sh` into the same `USER 1001` install RUN as `uv pip install`, reducing GitHub Actions amd64 peak disk usage from ENOSPC at 100% to approximately 58–59% for both Jupyter and runtime builds. Follow-up alignment with main’s OpenShift permission and de-vendor layering is tracked separately in GitHub issue `#2650`.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

_{You are interacting with an AI system.}