feat(ppc64le): build runtime datascience image on ppc64le #2215
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Warning Rate limit exceeded@jiridanek has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 6 minutes and 48 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (6)
WalkthroughAdds TARGETARCH-driven multi-arch build support: introduces architecture-conditional build stages and environment for ppc64le in the datascience Dockerfile, updates package gating in pylock.toml to explicitly exclude ppc64le/s390x in many markers, excludes codeflare-sdk on ppc64le, and expands pipeline/platform mappings to include linux/ppc64le. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related issues
Possibly related PRs
Suggested labels
✨ Finishing Touches
🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
Status, Documentation and Community
|
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Able to build image locally: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 11
🧹 Nitpick comments (4)
runtimes/datascience/ubi9-python-3.12/pyproject.toml (1)
18-18: Lock file gating verified; align quoting
- The lock file already includes
marker = "platform_machine != 'ppc64le"under[[packages]]forcodeflare-sdk.- Apply the quoting nit in
pyproject.tomlfor consistency:- "codeflare-sdk~=0.29.0; platform_machine != 'ppc64le'" + 'codeflare-sdk~=0.29.0; platform_machine != "ppc64le"'
- If you re-run verification, update the grep to look for
marker =(singular) instead ofmarkers =.runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu (3)
30-37: Profile exports won’t affect non-login shells during build.These envs won’t be loaded in later RUN steps. Keep them, but also export where used (see GRPC fix below).
81-101: ONNX builder: reproducibility and toolchain.
- Now that git is added, build proceeds; still, building from a moving requirements.txt is non-reproducible. Consider pinning via constraints or using a known tag’s locked reqs.
If staying source-built, consider:
- pip install -r requirements.txt && \ + pip install --disable-pip-version-check -r requirements.txt && \ export CMAKE_ARGS="-DPython3_EXECUTABLE=$(which python3.12)" && \ pip wheel . -w /onnx_wheels; \Also consider verifying manylinux tags on produced wheels.
102-104: Drop dummy control file; avoid copying to /dev/null later.The extra control file and /dev/null copy are unnecessary and potentially brittle.
Apply:
-# Create dummy control file -RUN touch /tmp/controlAnd remove the corresponding COPY in the runtime stage (see below).
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (3)
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu(3 hunks)runtimes/datascience/ubi9-python-3.12/pylock.toml(36 hunks)runtimes/datascience/ubi9-python-3.12/pyproject.toml(2 hunks)
🧰 Additional context used
🧠 Learnings (8)
📓 Common learnings
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-05T17:24:08.616Z
Learning: jiridanek requested PR review for #1521 covering s390x architecture support improvements, demonstrating continued focus on systematic multi-architecture compatibility enhancements in the opendatahub-io/notebooks repository through clean implementation with centralized configuration, proper CI integration, and architecture-aware testing patterns.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/rocm-tensorflow/ubi9-python-3.12/pyproject.toml:75-77
Timestamp: 2025-08-27T15:33:28.871Z
Learning: jiridanek requested GitHub issue creation for multi-architecture environment exploration during PR #2145 review, specifically to investigate architecture-specific environments for ROCm TensorFlow wheel optimization across x86_64, aarch64, ppc64le, and s390x architectures, noting uncertainty about implementation benefits but wanting systematic exploration through issue tracking. Issue #2158 was created with comprehensive analysis covering current limitations, investigation areas, multiple solution options, and clear acceptance criteria.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/rocm-tensorflow/ubi9-python-3.12/pyproject.toml:75-77
Timestamp: 2025-08-27T15:33:28.871Z
Learning: jiridanek requested GitHub issue creation for multi-architecture environment exploration during PR #2145 review, specifically to investigate architecture-specific environments for ROCm TensorFlow wheel optimization across x86_64, aarch64, ppc64le, and s390x architectures, noting uncertainty about implementation benefits but wanting systematic exploration through issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:42-52
Timestamp: 2025-07-09T12:29:56.162Z
Learning: jiridanek requested GitHub issue creation for OpenShift client architecture mapping problem affecting 29 Dockerfiles during PR #1320 review. Issue was created with comprehensive analysis covering all affected files using $(uname -m) returning 'aarch64' but OpenShift mirror expecting 'arm64', systematic solution using BuildKit TARGETARCH mapping with proper amd64→x86_64 and arm64→arm64 conversion, detailed acceptance criteria, and implementation guidance, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/pytorch+llmcompressor/ubi9-python-3.12/Dockerfile.cuda:152-159
Timestamp: 2025-08-27T14:49:24.112Z
Learning: jiridanek requested GitHub issue creation for CUDA version alignment in pytorch+llmcompressor runtime during PR #2145 review. Issue #2148 was created addressing the mismatch between Dockerfile CUDA 12.6 and pylock.toml cu124 PyTorch wheels. The issue includes comprehensive problem description covering affected files (runtimes/pytorch+llmcompressor/ubi9-python-3.12/Dockerfile.cuda and pylock.toml), detailed solution with PyTorch index URL update from cu124 to cu126, lock regeneration steps using uv, clear acceptance criteria for wheel alignment verification, and proper context linking to PR #2145 review comment, assigned to jiridanek.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:40-42
Timestamp: 2025-07-04T17:08:02.399Z
Learning: In the opendatahub-io/notebooks repository, when using multi-architecture Dockerfiles with BuildKit, the implicit build argument TARGETARCH is automatically available in the global scope for FROM instructions without explicit declaration. However, if TARGETARCH is used within a build stage, it must be declared explicitly within that stage. The current placement pattern (declaring ARG TARGETARCH after FROM instructions that use it) is correct for modern Docker/Podman/Buildah environments and does not require compatibility with older Docker versions.
Learnt from: atheo89
PR: opendatahub-io/notebooks#1258
File: codeserver/ubi9-python-3.11/Dockerfile.cpu:32-32
Timestamp: 2025-07-07T11:08:48.524Z
Learning: atheo89 requested GitHub issue creation for multi-architecture Dockerfile improvements during PR #1258 review, specifically for enhancing structural consistency across Docker stages, replacing $(uname -m) with ${TARGETARCH} for cross-architecture builds, and adding OCI-compliant metadata labels. Issue #1332 was created with comprehensive problem description, phased implementation approach, detailed acceptance criteria, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:50-50
Timestamp: 2025-07-08T19:30:01.738Z
Learning: jiridanek requested GitHub issue creation for multi-architecture support in ROCm TensorFlow image during PR #1333 review. Issue #1346 was created with comprehensive problem description covering hardcoded x86_64 architecture breaking multi-arch support, detailed impact analysis, three solution options (runtime detection, BuildKit TARGETARCH integration, hybrid approach) with pros/cons analysis, comprehensive acceptance criteria covering core requirements and testing, phased implementation guidance, related files identification, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2180
File: .tekton/odh-base-image-cuda-py312-ubi9-pull-request.yaml:36-39
Timestamp: 2025-08-28T12:42:23.404Z
Learning: Konflux build system in opendatahub-io/notebooks repository requires "linux/x86_64" platform identifier format for Tekton PipelineRun build-platforms parameter, not the OCI-standard "linux/amd64". This is consistently used across all .tekton/ pipeline files and enforced by scripts/generate_pull_request_pipelineruns.py type definitions. Docker/buildah contexts use "linux/amd64" while Konflux/Tekton contexts use "linux/x86_64".
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2180
File: base-images/rocm/6.2/ubi9-python-3.12/Dockerfile.rocm:32-34
Timestamp: 2025-08-28T12:43:09.835Z
Learning: Issue #1346 "Multi-architecture support for ROCm TensorFlow runtime image" already covers hardcoded RHEL point release and architecture mapping problems in ROCm Dockerfiles, specifically documenting the hardcoded "rhel/9.4/main/x86_64" pattern in amdgpu repository URLs that breaks multi-architecture builds. This issue should be referenced when encountering similar hardcoded architecture patterns in ROCm base images.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/tensorflow/ubi9-python-3.12/Dockerfile.cuda:38-38
Timestamp: 2025-07-08T19:30:20.513Z
Learning: jiridanek requested GitHub issue creation for multi-architecture support in TensorFlow CUDA runtime image during PR #1333 review. Issue was created with comprehensive problem description covering hardcoded NVARCH limitation, multiple solution options using TARGETARCH build argument with architecture mapping, acceptance criteria for multi-architecture builds, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
📚 Learning: 2025-07-04T17:08:02.399Z
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:40-42
Timestamp: 2025-07-04T17:08:02.399Z
Learning: In the opendatahub-io/notebooks repository, when using multi-architecture Dockerfiles with BuildKit, the implicit build argument TARGETARCH is automatically available in the global scope for FROM instructions without explicit declaration. However, if TARGETARCH is used within a build stage, it must be declared explicitly within that stage. The current placement pattern (declaring ARG TARGETARCH after FROM instructions that use it) is correct for modern Docker/Podman/Buildah environments and does not require compatibility with older Docker versions.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-07-07T11:08:48.524Z
Learnt from: atheo89
PR: opendatahub-io/notebooks#1258
File: codeserver/ubi9-python-3.11/Dockerfile.cpu:32-32
Timestamp: 2025-07-07T11:08:48.524Z
Learning: atheo89 requested GitHub issue creation for multi-architecture Dockerfile improvements during PR #1258 review, specifically for enhancing structural consistency across Docker stages, replacing $(uname -m) with ${TARGETARCH} for cross-architecture builds, and adding OCI-compliant metadata labels. Issue #1332 was created with comprehensive problem description, phased implementation approach, detailed acceptance criteria, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-07-09T12:29:56.162Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:42-52
Timestamp: 2025-07-09T12:29:56.162Z
Learning: jiridanek requested GitHub issue creation for OpenShift client architecture mapping problem affecting 29 Dockerfiles during PR #1320 review. Issue was created with comprehensive analysis covering all affected files using $(uname -m) returning 'aarch64' but OpenShift mirror expecting 'arm64', systematic solution using BuildKit TARGETARCH mapping with proper amd64→x86_64 and arm64→arm64 conversion, detailed acceptance criteria, and implementation guidance, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-07-04T17:07:52.656Z
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: jupyter/minimal/ubi9-python-3.11/Dockerfile.cuda:29-38
Timestamp: 2025-07-04T17:07:52.656Z
Learning: In the opendatahub-io/notebooks repository, modern Docker with BuildKit automatically provides build arguments like TARGETARCH in the global scope for FROM instructions, but these arguments must be explicitly declared with ARG statements inside build stages where they will be used. The ARG declaration should be placed within the stage that uses it, not moved to the global scope, as this is the correct pattern for modern Docker/Podman/Buildah environments.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-28T12:43:09.835Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2180
File: base-images/rocm/6.2/ubi9-python-3.12/Dockerfile.rocm:32-34
Timestamp: 2025-08-28T12:43:09.835Z
Learning: Issue #1346 "Multi-architecture support for ROCm TensorFlow runtime image" already covers hardcoded RHEL point release and architecture mapping problems in ROCm Dockerfiles, specifically documenting the hardcoded "rhel/9.4/main/x86_64" pattern in amdgpu repository URLs that breaks multi-architecture builds. This issue should be referenced when encountering similar hardcoded architecture patterns in ROCm base images.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-05T17:24:08.616Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-05T17:24:08.616Z
Learning: jiridanek requested PR review for #1521 covering s390x architecture support improvements, demonstrating continued focus on systematic multi-architecture compatibility enhancements in the opendatahub-io/notebooks repository through clean implementation with centralized configuration, proper CI integration, and architecture-aware testing patterns.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-07T12:41:48.997Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1720
File: jupyter/pytorch+llmcompressor/ubi9-python-3.11/requirements.txt:2659-2680
Timestamp: 2025-08-07T12:41:48.997Z
Learning: For opendatahub-io/notebooks, rpds-py 0.27.0 provides manylinux wheels for Python 3.11 and 3.12 on x86_64 and aarch64, so no Rust build is needed for these platforms. For s390x and ppc64le, wheels are not available, so a Rust build stage or version pinning is required if those images are built.
Applied to files:
runtimes/datascience/ubi9-python-3.12/pylock.toml
🪛 Checkov (3.2.334)
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
[MEDIUM] 19-28: Ensure that packages with untrusted or missing GPG signatures are not used by dnf, tdnf, or yum via the '--nogpgcheck' option
(CKV2_DOCKER_9)
🔇 Additional comments (43)
runtimes/datascience/ubi9-python-3.12/pyproject.toml (1)
55-55: No functional change; uv environments block remains correct for Linux CPython.Looks good to keep the environment scope explicit.
runtimes/datascience/ubi9-python-3.12/pylock.toml (39)
180-180: LGTM: bcrypt excluded on ppc64le.
262-262: LGTM: cachetools exclusion consistent.
440-440: Matches PR objective: skip codeflare-sdk on ppc64le.
447-447: Question: Why exclude colorful on ppc64le?colorful is pure-Python; unless it pulls in arch-problematic deps, exclusion may be unnecessary.
Would you confirm if this was intentional or collateral from lock regen?
538-538: Risk: cryptography removal may break transitive features.Excluding cryptography can disable TLS/SSH flows through deps (e.g., paramiko). Confirm no remaining included deps require it at runtime.
Run a quick scan in pyproject/requirements for packages requiring cryptography and confirm feature parity on ppc64le.
622-622: LGTM: distlib exclusion.
635-635: LGTM: durationpy exclusion.
660-660: LGTM: filelock exclusion.
666-726: Version bump: fonttools 4.59.2 — verify downstream compatibility.Looks fine, but please confirm no stricter pins in pyproject or Jupyter stack that would conflict.
842-842: LGTM: fsspec/google- exclusions align with arch gating.*Also applies to: 849-849, 856-856
870-870: LGTM: grpcio excluded on ppc64le.
934-934: LGTM: invoke exclusion.
965-965: User experience check: ipywidgets removed on ppc64le.Jupyter UX may degrade without widgets. Intentional?
1026-1026: Follow-up: jupyterlab-widgets also excluded.Confirm widget story on ppc64le (acceptable or documented limitation).
1146-1146: Kubernetes client excluded — confirm no cluster integrations required.Many notebook flows assume k8s client availability.
1153-1153: LGTM: markdown-it-py exclusion.
1294-1294: LGTM: mdurl exclusion.
1354-1354: LGTM: msgpack exclusion.
1661-1661: LGTM: oauthlib exclusion.
1714-1714: LGTM: opencensus, openshift-client excluded.*Also applies to: 1721-1721, 1728-1728
1801-1801: LGTM: paramiko excluded (avoids cryptography/bcrypt/pynacl tree).
1945-1945: Check: Removing prometheus-client may drop metrics.If any included server (e.g., jupyter-server) expects it, confirm no regressions.
1951-1953: prompt-toolkit 3.0.52 bump — confirm Jupyter compatibility.Generally safe, but verify with jupyter-console/ipython versions in lock.
2063-2063: LGTM: proto-plus exclusion.
2120-2120: LGTM: py-spy excluded on ppc64le.
2135-2135: LGTM: pyarrow excluded (no ppc64le wheels).
2185-2185: LGTM: pyasn1, pyasn1-modules exclusions.Also applies to: 2192-2192
2253-2253: LGTM: pydantic exclusion.
2379-2379: LGTM: PyNaCl exclusion.
2631-2631: LGTM: ray exclusion (expected on non-x86).
2674-2674: LGTM: requests-oauthlib and rich exclusions.Also applies to: 2681-2681
2849-2849: LGTM: rsa exclusion.
2969-2969: LGTM: smart-open exclusion.
2974-2976: soupsieve 2.8 bump — verify BeautifulSoup compatibility.Should be fine; double-check tests/notebook imports.
3053-3053: LGTM: virtualenv exclusion.
3072-3072: LGTM: websocket-client exclusion.
3086-3086: UX check: widgetsnbextension excluded.Pairs with ipywidgets; confirm documented limitation for ppc64le.
3092-3092: LGTM: wrapt exclusion.
2199-2199: Same "or" leak: pycparser.If you intend to exclude on ppc64le, drop the python clause.
- marker = "python_full_version < '3.14' or platform_machine != 'ppc64le'" + marker = "platform_machine != 'ppc64le'"Likely an incorrect or invalid review comment.
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu (3)
11-12: ARG TARGETARCH placement is correct for BuildKit stages.Good adherence to the repo’s multi-arch pattern.
53-56: Stage labeling and metadata look fine.Consistent stage structure and metadata; no concerns here.
Also applies to: 77-80, 105-123
46-51: Ignore arch‐mapping change; existing code is correct.
The OpenShift mirror at https://mirror.openshift.com/pub/openshift-v4/ supports both “aarch64” and “arm64” directories, so using$(uname -m)works on all TARGETARCH values without modification.Likely an incorrect or invalid review comment.
Comment on lines
57
to
168
| FROM base AS openblas-builder | ||
| USER root | ||
| WORKDIR /root | ||
|
|
||
| ARG TARGETARCH | ||
|
|
||
| ENV OPENBLAS_VERSION=0.3.30 | ||
|
|
||
| RUN echo "openblas-builder stage TARGETARCH: ${TARGETARCH}" | ||
|
|
||
| # Download and build OpenBLAS | ||
| RUN if [ "$TARGETARCH" = "ppc64le" ]; then \ | ||
| source /opt/rh/gcc-toolset-13/enable && \ | ||
| wget https://github.com/OpenMathLib/OpenBLAS/releases/download/v${OPENBLAS_VERSION}/OpenBLAS-${OPENBLAS_VERSION}.zip && \ | ||
| unzip OpenBLAS-${OPENBLAS_VERSION}.zip && cd OpenBLAS-${OPENBLAS_VERSION} && \ | ||
| make -j$(nproc) TARGET=POWER9 BINARY=64 USE_OPENMP=1 USE_THREAD=1 NUM_THREADS=120 DYNAMIC_ARCH=1 INTERFACE64=0; \ | ||
| else \ | ||
| echo "Not ppc64le, skipping OpenBLAS build" && mkdir -p /root/dummy; \ | ||
| fi | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
OpenBLAS artifact path leads to runtime install failure; add checksum and sane NUM_THREADS.
- Later COPY uses /root/OpenBLAS-* and then
make -C /openblas install; /openblas won’t contain a Makefile root. Fix to a deterministic path. - Add checksum verification for supply-chain integrity.
- NUM_THREADS=120 bakes a huge default thread count into the library; prefer leaving it unset or tie to $(nproc).
Apply:
FROM base AS openblas-builder
@@
-RUN if [ "$TARGETARCH" = "ppc64le" ]; then \
- source /opt/rh/gcc-toolset-13/enable && \
- wget https://github.com/OpenMathLib/OpenBLAS/releases/download/v${OPENBLAS_VERSION}/OpenBLAS-${OPENBLAS_VERSION}.zip && \
- unzip OpenBLAS-${OPENBLAS_VERSION}.zip && cd OpenBLAS-${OPENBLAS_VERSION} && \
- make -j$(nproc) TARGET=POWER9 BINARY=64 USE_OPENMP=1 USE_THREAD=1 NUM_THREADS=120 DYNAMIC_ARCH=1 INTERFACE64=0; \
+RUN if [ "$TARGETARCH" = "ppc64le" ]; then \
+ source /opt/rh/gcc-toolset-13/enable && \
+ wget -O OpenBLAS-${OPENBLAS_VERSION}.zip https://github.com/OpenMathLib/OpenBLAS/releases/download/v${OPENBLAS_VERSION}/OpenBLAS-${OPENBLAS_VERSION}.zip && \
+ unzip OpenBLAS-${OPENBLAS_VERSION}.zip && \
+ cd OpenBLAS-${OPENBLAS_VERSION} && \
+ make -j"$(nproc)" TARGET=POWER9 BINARY=64 USE_OPENMP=1 USE_THREAD=1 INTERFACE64=0 && \
+ cd /root && mv "OpenBLAS-${OPENBLAS_VERSION}" /opt/openblas-src; \
else \
echo "Not ppc64le, skipping OpenBLAS build" && mkdir -p /root/dummy; \
fiOptional: add a SHA256 check before unzip.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| FROM base AS openblas-builder | |
| USER root | |
| WORKDIR /root | |
| ARG TARGETARCH | |
| ENV OPENBLAS_VERSION=0.3.30 | |
| RUN echo "openblas-builder stage TARGETARCH: ${TARGETARCH}" | |
| # Download and build OpenBLAS | |
| RUN if [ "$TARGETARCH" = "ppc64le" ]; then \ | |
| source /opt/rh/gcc-toolset-13/enable && \ | |
| wget https://github.com/OpenMathLib/OpenBLAS/releases/download/v${OPENBLAS_VERSION}/OpenBLAS-${OPENBLAS_VERSION}.zip && \ | |
| unzip OpenBLAS-${OPENBLAS_VERSION}.zip && cd OpenBLAS-${OPENBLAS_VERSION} && \ | |
| make -j$(nproc) TARGET=POWER9 BINARY=64 USE_OPENMP=1 USE_THREAD=1 NUM_THREADS=120 DYNAMIC_ARCH=1 INTERFACE64=0; \ | |
| else \ | |
| echo "Not ppc64le, skipping OpenBLAS build" && mkdir -p /root/dummy; \ | |
| fi | |
| FROM base AS openblas-builder | |
| USER root | |
| WORKDIR /root | |
| ARG TARGETARCH | |
| ENV OPENBLAS_VERSION=0.3.30 | |
| RUN echo "openblas-builder stage TARGETARCH: ${TARGETARCH}" | |
| # Download and build OpenBLAS | |
| RUN if [ "$TARGETARCH" = "ppc64le" ]; then \ | |
| source /opt/rh/gcc-toolset-13/enable && \ | |
| wget -O OpenBLAS-${OPENBLAS_VERSION}.zip https://github.com/OpenMathLib/OpenBLAS/releases/download/v${OPENBLAS_VERSION}/OpenBLAS-${OPENBLAS_VERSION}.zip && \ | |
| unzip OpenBLAS-${OPENBLAS_VERSION}.zip && \ | |
| cd OpenBLAS-${OPENBLAS_VERSION} && \ | |
| make -j"$(nproc)" TARGET=POWER9 BINARY=64 USE_OPENMP=1 USE_THREAD=1 INTERFACE64=0 && \ | |
| cd /root && mv "OpenBLAS-${OPENBLAS_VERSION}" /opt/openblas-src; \ | |
| else \ | |
| echo "Not ppc64le, skipping OpenBLAS build" && mkdir -p /root/dummy; \ | |
| fi |
🤖 Prompt for AI Agents
In runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu around lines 57-76, the
OpenBLAS build stage uses a non-deterministic/artifact location and an unsafe
large NUM_THREADS value; change the build to extract and build in a fixed
directory (e.g., /root/OpenBLAS-${OPENBLAS_VERSION}) so later COPY/MAKE -C paths
point to a real Makefile location, add a SHA256 checksum verification step
before unzip (download the .zip and its .sha256, verify with sha256sum -c), and
remove the hardcoded NUM_THREADS=120 (either omit NUM_THREADS so OpenBLAS
defaults or set NUM_THREADS=$(nproc)); ensure the install line later uses the
exact deterministic build directory you create.
Comment on lines
124
to
228
| USER 0 | ||
|
|
||
| # Install ppc64le-built wheels if available | ||
| COPY --from=openblas-builder /root/OpenBLAS-* /openblas | ||
| COPY --from=onnx-builder /tmp/control /dev/null | ||
| COPY --from=onnx-builder /onnx_wheels /tmp/onnx_wheels | ||
|
|
||
| RUN if [ "$TARGETARCH" = "ppc64le" ]; then \ | ||
| echo "Installing ppc64le ONNX wheels and OpenBLAS..." && \ | ||
| HOME=/root pip install /tmp/onnx_wheels/*.whl && \ | ||
| if [ -d "/openblas" ] && [ "$(ls -A /openblas 2>/dev/null)" ]; then \ | ||
| PREFIX=/usr/local make -C /openblas install; \ | ||
| fi && rm -rf /openblas /tmp/onnx_wheels; \ | ||
| else \ | ||
| echo "Skipping architecture-specific wheel installs for (${TARGETARCH})" && \ | ||
| rm -rf /tmp/wheels /openblas /tmp/onnx_wheels; \ | ||
| fi |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Fix OpenBLAS COPY/install path; remove /dev/null COPY; guard wheel glob.
- Current
make -C /openblas installwon’t find a Makefile. - Copying to /dev/null is odd; just drop it.
- Ensure wheel glob only runs when files exist.
Apply:
USER 0
-# Install ppc64le-built wheels if available
-COPY --from=openblas-builder /root/OpenBLAS-* /openblas
-COPY --from=onnx-builder /tmp/control /dev/null
-COPY --from=onnx-builder /onnx_wheels /tmp/onnx_wheels
+# Install ppc64le-built wheels if available
+COPY --from=openblas-builder /opt/openblas-src /openblas
+COPY --from=onnx-builder /onnx_wheels /tmp/onnx_wheels
-RUN if [ "$TARGETARCH" = "ppc64le" ]; then \
+RUN if [ "$TARGETARCH" = "ppc64le" ]; then \
echo "Installing ppc64le ONNX wheels and OpenBLAS..." && \
- HOME=/root pip install /tmp/onnx_wheels/*.whl && \
- if [ -d "/openblas" ] && [ "$(ls -A /openblas 2>/dev/null)" ]; then \
- PREFIX=/usr/local make -C /openblas install; \
+ if compgen -G "/tmp/onnx_wheels/*.whl" > /dev/null; then \
+ HOME=/root pip install /tmp/onnx_wheels/*.whl; \
+ fi && \
+ if [ -d "/openblas" ]; then \
+ PREFIX=/usr/local make -C /openblas install; \
fi && rm -rf /openblas /tmp/onnx_wheels; \
else \
echo "Skipping architecture-specific wheel installs for (${TARGETARCH})" && \
rm -rf /tmp/wheels /openblas /tmp/onnx_wheels; \
fi📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| USER 0 | |
| # Install ppc64le-built wheels if available | |
| COPY --from=openblas-builder /root/OpenBLAS-* /openblas | |
| COPY --from=onnx-builder /tmp/control /dev/null | |
| COPY --from=onnx-builder /onnx_wheels /tmp/onnx_wheels | |
| RUN if [ "$TARGETARCH" = "ppc64le" ]; then \ | |
| echo "Installing ppc64le ONNX wheels and OpenBLAS..." && \ | |
| HOME=/root pip install /tmp/onnx_wheels/*.whl && \ | |
| if [ -d "/openblas" ] && [ "$(ls -A /openblas 2>/dev/null)" ]; then \ | |
| PREFIX=/usr/local make -C /openblas install; \ | |
| fi && rm -rf /openblas /tmp/onnx_wheels; \ | |
| else \ | |
| echo "Skipping architecture-specific wheel installs for (${TARGETARCH})" && \ | |
| rm -rf /tmp/wheels /openblas /tmp/onnx_wheels; \ | |
| fi | |
| USER 0 | |
| # Install ppc64le-built wheels if available | |
| COPY --from=openblas-builder /opt/openblas-src /openblas | |
| COPY --from=onnx-builder /onnx_wheels /tmp/onnx_wheels | |
| RUN if [ "$TARGETARCH" = "ppc64le" ]; then \ | |
| echo "Installing ppc64le ONNX wheels and OpenBLAS..." && \ | |
| if compgen -G "/tmp/onnx_wheels/*.whl" > /dev/null; then \ | |
| HOME=/root pip install /tmp/onnx_wheels/*.whl; \ | |
| fi && \ | |
| if [ -d "/openblas" ]; then \ | |
| PREFIX=/usr/local make -C /openblas install; \ | |
| fi && rm -rf /openblas /tmp/onnx_wheels; \ | |
| else \ | |
| echo "Skipping architecture-specific wheel installs for (${TARGETARCH})" && \ | |
| rm -rf /tmp/wheels /openblas /tmp/onnx_wheels; \ | |
| fi |
🤖 Prompt for AI Agents
In runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu around lines 124-140,
the Dockerfile copies OpenBLAS archives but then runs make in /openblas where no
Makefile exists, copies a file to /dev/null unnecessarily, and unguardedly globs
wheels which will fail when none exist; fix by copying the OpenBLAS build
directory that contains the Makefile (preserve the directory name from the
builder into /openblas_src or similar) and run make -C against that actual
directory, remove the COPY to /dev/null, and wrap the pip install step in a
guard that only runs if /tmp/onnx_wheels/*.whl actually exist (e.g., check for
existence of at least one .whl before invoking pip), and tidy the rm -rf targets
to remove only the copied build/artifact dirs.
Comment on lines
147
to
263
| RUN --mount=type=cache,target=/root/.cache/pip \ | ||
| echo "Installing softwares and packages" && \ | ||
| if [ "$TARGETARCH" = "ppc64le" ]; then \ | ||
| export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig; \ | ||
| export LD_LIBRARY_PATH=/usr/local/lib64:/usr/local/lib:/usr/lib64:/usr/lib:$LD_LIBRARY_PATH; \ | ||
| GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1 && \ | ||
| pip install ml-dtypes && \ | ||
| uv pip install --strict --no-deps --no-cache --no-config --no-progress --verify-hashes --compile-bytecode --index-strategy=unsafe-best-match --requirements=./pylock.toml; \ | ||
| else \ | ||
| # This may have to download and compile some dependencies, and as we don't lock requirements from `build-system.requires`, | ||
| # we often don't know the correct hashes and `--require-hashes` would therefore fail on non amd64, where building is common. | ||
| uv pip install --strict --no-deps --no-cache --no-config --no-progress --verify-hashes --compile-bytecode --index-strategy=unsafe-best-match --requirements=./pylock.toml && \ | ||
| # Fix permissions to support pip in Openshift environments \ | ||
| uv pip install --strict --no-deps --no-cache --no-config --no-progress --verify-hashes --compile-bytecode --index-strategy=unsafe-best-match --requirements=./pylock.toml; \ | ||
| fi && \ |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Fix GRPC_OPENSSL export; reconsider out-of-lock ml-dtypes.
GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1 && \is a no-op; export or prefix the pip command.- Installing ml-dtypes outside the lock breaks reproducibility and may fail on ppc64le; prefer adding it to pyproject with a platform marker and regenerating pylock, or drop it here.
Apply:
RUN --mount=type=cache,target=/root/.cache/pip \
echo "Installing softwares and packages" && \
if [ "$TARGETARCH" = "ppc64le" ]; then \
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig; \
export LD_LIBRARY_PATH=/usr/local/lib64:/usr/local/lib:/usr/lib64:/usr/lib:$LD_LIBRARY_PATH; \
- GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1 && \
- pip install ml-dtypes && \
+ export GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1; \
+ # Consider moving ml-dtypes to pyproject with a platform marker and re-locking, then install via uv only.
+ # pip install ml-dtypes && \
uv pip install --strict --no-deps --no-cache --no-config --no-progress --verify-hashes --compile-bytecode --index-strategy=unsafe-best-match --requirements=./pylock.toml; \
else \
@@
uv pip install --strict --no-deps --no-cache --no-config --no-progress --verify-hashes --compile-bytecode --index-strategy=unsafe-best-match --requirements=./pylock.toml; \If ml-dtypes is required, I can update pyproject.toml with platform_system == "Linux" and platform_machine == "ppc64le" and regenerate pylock.
🏁 Script executed:
#!/bin/bash
set -eux
# Show the Dockerfile snippet around lines 140–175
sed -n '140,175p' runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
# Confirm the GRPC_PYTHON_BUILD_SYSTEM_OPENSSL assignment and its context
grep -n 'GRPC_PYTHON_BUILD_SYSTEM_OPENSSL' runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
# Confirm the out-of-lock installation of ml-dtypes
grep -n 'pip install ml-dtypes' runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
# Search for ml-dtypes in project configuration and lock files
grep -R 'ml-dtypes' pyproject.toml pylock.toml || trueLength of output: 1979
Export GRPC_PYTHON_BUILD_SYSTEM_OPENSSL and lock ml-dtypes
- Change the bare assignment
GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1 && \toexport GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1; \so the variable is inherited by the pip subprocess. - Remove the out-of-lock
pip install ml-dtypesand instead add ml-dtypes to your project’s pyproject.toml (with aplatform_machine == "ppc64le"marker), regenerate the lockfile, and install it via the locked requirements.
Apply:
RUN --mount=type=cache,target=/root/.cache/pip \
echo "Installing softwares and packages" && \
if [ "$TARGETARCH" = "ppc64le" ]; then \
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig; \
export LD_LIBRARY_PATH=/usr/local/lib64:/usr/local/lib:/usr/lib64:/usr/lib:$LD_LIBRARY_PATH; \
- GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1 && \
- pip install ml-dtypes && \
+ export GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1; \
+ # ml-dtypes must be locked in pyproject.toml for reproducibility; remove this direct install.
uv pip install --strict --no-deps --no-cache --no-config --no-progress --verify-hashes --compile-bytecode --index-strategy=unsafe-best-match --requirements=./pylock.toml; \
else \📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| RUN --mount=type=cache,target=/root/.cache/pip \ | |
| echo "Installing softwares and packages" && \ | |
| if [ "$TARGETARCH" = "ppc64le" ]; then \ | |
| export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig; \ | |
| export LD_LIBRARY_PATH=/usr/local/lib64:/usr/local/lib:/usr/lib64:/usr/lib:$LD_LIBRARY_PATH; \ | |
| GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1 && \ | |
| pip install ml-dtypes && \ | |
| uv pip install --strict --no-deps --no-cache --no-config --no-progress --verify-hashes --compile-bytecode --index-strategy=unsafe-best-match --requirements=./pylock.toml; \ | |
| else \ | |
| # This may have to download and compile some dependencies, and as we don't lock requirements from `build-system.requires`, | |
| # we often don't know the correct hashes and `--require-hashes` would therefore fail on non amd64, where building is common. | |
| uv pip install --strict --no-deps --no-cache --no-config --no-progress --verify-hashes --compile-bytecode --index-strategy=unsafe-best-match --requirements=./pylock.toml && \ | |
| # Fix permissions to support pip in Openshift environments \ | |
| uv pip install --strict --no-deps --no-cache --no-config --no-progress --verify-hashes --compile-bytecode --index-strategy=unsafe-best-match --requirements=./pylock.toml; \ | |
| fi && \ | |
| RUN --mount=type=cache,target=/root/.cache/pip \ | |
| echo "Installing softwares and packages" && \ | |
| if [ "$TARGETARCH" = "ppc64le" ]; then \ | |
| export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig; \ | |
| export LD_LIBRARY_PATH=/usr/local/lib64:/usr/local/lib:/usr/lib64:/usr/lib:$LD_LIBRARY_PATH; \ | |
| export GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1; \ | |
| # ml-dtypes must be locked in pyproject.toml for reproducibility; remove this direct install. | |
| uv pip install --strict --no-deps --no-cache --no-config --no-progress \ | |
| --verify-hashes --compile-bytecode --index-strategy=unsafe-best-match \ | |
| --requirements=./pylock.toml; \ | |
| else \ | |
| # This may have to download and compile some dependencies, and as we don't lock requirements from | |
| # `build-system.requires`, we often don't know the correct hashes and `--require-hashes` would | |
| # therefore fail on non amd64, where building is common. | |
| uv pip install --strict --no-deps --no-cache --no-config --no-progress \ | |
| --verify-hashes --compile-bytecode --index-strategy=unsafe-best-match \ | |
| --requirements=./pylock.toml; \ | |
| fi && \ |
🤖 Prompt for AI Agents
In runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu around lines 147 to 159,
replace the bare assignment "GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1 &&" with an
exported environment variable so the pip subprocess inherits it (use "export
GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1;" or equivalent), remove the out-of-lock "pip
install ml-dtypes" invocation from the Dockerfile, add ml-dtypes to
pyproject.toml with a platform marker 'platform_machine == "ppc64le"',
regenerate the lockfile (pylock.toml) so ml-dtypes is present in the locked
requirements, and keep the pip install step reliant on the regenerated lockfile
so all installs are satisfied via the lock rather than an ad-hoc pip install.
|
Validated Runtime datascience Image: |
github-actions
bot
added
the
review-requested
AaruniAggarwal
force-pushed
the
runtime-datascience-ppc64le
branch
from
37b7c98 to
8f4a228
Compare
There was a problem hiding this comment.
Actionable comments posted: 26
♻️ Duplicate comments (10)
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu (4)
146-158: Export GRPC_OPENSSL; avoid out-of-lock ml-dtypes.Bare assignment doesn’t reach pip; and ad hoc installs break reproducibility, especially on ppc64le.
Apply:
if [ "$TARGETARCH" = "ppc64le" ]; then \ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig; \ export LD_LIBRARY_PATH=/usr/local/lib64:/usr/local/lib:/usr/lib64:/usr/lib:$LD_LIBRARY_PATH; \ - GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1 && \ - pip install ml-dtypes && \ + export GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1; \ uv pip install --strict --no-deps --no-cache --no-config --no-progress --verify-hashes --compile-bytecode --index-strategy=unsafe-best-match --requirements=./pylock.toml; \Follow-up: add ml-dtypes to pyproject.toml with platform marker (platform_machine == "ppc64le") and regenerate pylock.toml; then remove any standalone pip install.
57-76: OpenBLAS build: deterministic path, drop NUM_THREADS=120, add checksum.Later install expects a stable source dir; also avoid baking 120 threads; verify the archive.
Apply:
ARG TARGETARCH ENV OPENBLAS_VERSION=0.3.30 RUN echo "openblas-builder stage TARGETARCH: ${TARGETARCH}" -# Download and build OpenBLAS -RUN if [ "$TARGETARCH" = "ppc64le" ]; then \ - source /opt/rh/gcc-toolset-13/enable && \ - wget https://github.com/OpenMathLib/OpenBLAS/releases/download/v${OPENBLAS_VERSION}/OpenBLAS-${OPENBLAS_VERSION}.zip && \ - unzip OpenBLAS-${OPENBLAS_VERSION}.zip && cd OpenBLAS-${OPENBLAS_VERSION} && \ - make -j$(nproc) TARGET=POWER9 BINARY=64 USE_OPENMP=1 USE_THREAD=1 NUM_THREADS=120 DYNAMIC_ARCH=1 INTERFACE64=0; \ +ARG OPENBLAS_SHA256 +# Download and build OpenBLAS +RUN if [ "$TARGETARCH" = "ppc64le" ]; then \ + source /opt/rh/gcc-toolset-13/enable && \ + wget -O /root/OpenBLAS-${OPENBLAS_VERSION}.zip \ + "https://github.com/OpenMathLib/OpenBLAS/releases/download/v${OPENBLAS_VERSION}/OpenBLAS-${OPENBLAS_VERSION}.zip" && \ + if [ -n "${OPENBLAS_SHA256}" ]; then echo "${OPENBLAS_SHA256} /root/OpenBLAS-${OPENBLAS_VERSION}.zip" | sha256sum -c -; fi && \ + mkdir -p /opt/openblas-src && unzip -q /root/OpenBLAS-${OPENBLAS_VERSION}.zip -d /opt/openblas-src && \ + cd /opt/openblas-src/OpenBLAS-${OPENBLAS_VERSION} && \ + make -j"$(nproc)" TARGET=POWER9 BINARY=64 USE_OPENMP=1 USE_THREAD=1 INTERFACE64=0; \ else \ echo "Not ppc64le, skipping OpenBLAS build" && mkdir -p /root/dummy; \ fi
126-139: OpenBLAS COPY/Makefile path mismatch; guard wheel glob.make -C /openblas won’t find a Makefile when the zip extracted into a versioned subdir. Also guard the *.whl glob.
Apply:
-# Install ppc64le-built wheels if available -COPY --from=openblas-builder /root/OpenBLAS-* /openblas -COPY --from=onnx-builder /onnx_wheels /tmp/onnx_wheels +# Install ppc64le-built wheels if available +COPY --from=openblas-builder /opt/openblas-src /openblas +COPY --from=onnx-builder /onnx_wheels /tmp/onnx_wheels RUN if [ "$TARGETARCH" = "ppc64le" ]; then \ echo "Installing ppc64le ONNX wheels and OpenBLAS..." && \ - HOME=/root pip install /tmp/onnx_wheels/*.whl && \ - if [ -d "/openblas" ] && [ "$(ls -A /openblas 2>/dev/null)" ]; then \ - PREFIX=/usr/local make -C /openblas install; \ + if compgen -G "/tmp/onnx_wheels/*.whl" > /dev/null; then \ + HOME=/root pip install /tmp/onnx_wheels/*.whl; \ + fi && \ + if [ -d "/openblas" ] && compgen -G "/openblas/OpenBLAS-*" > /dev/null; then \ + PREFIX=/usr/local make -C "$(echo /openblas/OpenBLAS-*)" install; \ fi && rm -rf /openblas /tmp/onnx_wheels; \ else \ echo "Skipping architecture-specific wheel installs for (${TARGETARCH})" && \ rm -rf /tmp/wheels /openblas /tmp/onnx_wheels; \ fi
18-28: Drop insecure flags and ad-hoc ml-dtypes install
- Remove
--nogpgcheckfrom the DNF install commands inruntimes/datascience/ubi9-python-3.12/Dockerfile.cpu(lines 18–28 and 146–158).- Eliminate the unpinned
pip install ml-dtypesat line 152 and rely on the version locked inpylock.toml.runtimes/datascience/ubi9-python-3.12/pylock.toml (6)
10-10: "or" marker leaks onto ppc64le; re-lock with minimal gating.These markers will still install on ppc64le under Python 3.12. Prefer removing arch gating entirely (only codeflare-sdk should be excluded per PR) and regenerate the lock from pyproject. If you truly intend to exclude on ppc64le, switch to an intersection.
- marker = "python_full_version == '3.12.*' or platform_machine != 'ppc64le'" + marker = "python_full_version == '3.12.*' and platform_machine != 'ppc64le'"Run to find remaining leaking markers:
#!/bin/bash rg -nP "marker\s*=\s*\"[^\"]*or\s+platform_machine\s*!=\s*'ppc64le'\"" runtimes/datascience/ubi9-python-3.12/pylock.tomlAlso applies to: 17-17
110-110: Unnecessary gating + another "or" leak.
- aiohttp-cors is pure Python; don’t gate by arch.
- aiosignal uses the same leaking "or" pattern.
- marker = "platform_machine != 'ppc64le'" + # remove marker; let pyproject drive selection - marker = "python_full_version == '3.12.*' or platform_machine != 'ppc64le'" + marker = "platform_machine != 'ppc64le' and python_full_version == '3.12.*'"Preferred: remove both markers and re-lock from pyproject.
Also applies to: 117-117
1420-1420: Leaking "or" on multidict; fix or remove gating.- marker = "python_full_version == '3.12.*' or platform_machine != 'ppc64le'" + marker = "python_full_version == '3.12.*' and platform_machine != 'ppc64le'"Preferred: remove arch gating and re-lock.
1945-1945: Keep PR scoped; avoid unrelated bumps; fix another "or" leak.
- prometheus-client/prompt-toolkit versions changed; revert unless required by ppc64le work.
- propcache marker leaks onto ppc64le.
- marker = "python_full_version == '3.12.*' or platform_machine != 'ppc64le'" + marker = "python_full_version == '3.12.*' and platform_machine != 'ppc64le'"Also applies to: 1951-1953, 1958-1958
3180-3180: Leaking "or" on yarl; fix or remove gating.- marker = "python_full_version == '3.12.*' or platform_machine != 'ppc64le'" + marker = "python_full_version == '3.12.*' and platform_machine != 'ppc64le'"Preferred: drop the marker and re-lock.
275-275: Leaking "or" again on cffi; also, excluding cffi will cascade breakages.If cffi is needed, either ensure build deps on ppc64le or pin to a wheel-available version. At minimum, fix the logic if exclusion is truly intended.
- marker = "python_full_version < '3.14' or platform_machine != 'ppc64le'" + marker = "python_full_version < '3.14' and platform_machine != 'ppc64le'"Preferred: remove the marker and address build deps.
🧹 Nitpick comments (5)
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu (3)
30-37: Profile.d exports won’t affect RUNs; keep critical vars in-stage.Values echoed to /etc/profile.d are not sourced in non-login RUN steps. Don’t rely on these for build-time behavior (see GRPC var below).
81-101: ONNX builder: build only ONNX wheel; optionally shallow clone.Avoid building/transitively wheeling deps; you already installed them from requirements.
Apply:
- pip wheel . -w /onnx_wheels; \ + pip wheel . -w /onnx_wheels --no-deps; \Optional (size/time): add --depth=1 to git clone and submodules.
47-50: Use TARGETARCH mapping for oc client URL (fixes arm64).$(uname -m) returns aarch64, but the mirror expects arm64. Switch to TARGETARCH mapping so this image is robust across architectures.
Apply:
-RUN curl -L https://mirror.openshift.com/pub/openshift-v4/$(uname -m)/clients/ocp/stable/openshift-client-linux.tar.gz \ - -o /tmp/openshift-client-linux.tar.gz && \ - tar -xzvf /tmp/openshift-client-linux.tar.gz oc && \ - rm -f /tmp/openshift-client-linux.tar.gz +RUN ARCH="${TARGETARCH}"; \ + case "${ARCH}" in \ + amd64) OC_ARCH="x86_64" ;; \ + arm64) OC_ARCH="arm64" ;; \ + ppc64le) OC_ARCH="ppc64le";; \ + s390x) OC_ARCH="s390x" ;; \ + *) echo "Unsupported TARGETARCH: ${ARCH}" && exit 1 ;; \ + esac; \ + curl -L "https://mirror.openshift.com/pub/openshift-v4/${OC_ARCH}/clients/ocp/stable/openshift-client-linux.tar.gz" \ + -o /tmp/openshift-client-linux.tar.gz && \ + tar -xzvf /tmp/openshift-client-linux.tar.gz oc && rm -f /tmp/openshift-client-linux.tar.gzruntimes/datascience/ubi9-python-3.12/pylock.toml (2)
2135-2135: pyarrow is a common data science dependency; don’t silently drop it.If wheels are missing, consider: build from source, use Arrow C++ system libs, or document/track as a known limitation. Verify repo usage before exclusion.
I can open an issue to track pyarrow enablement on ppc64le with options and acceptance criteria.
2379-2379: PyNaCl: no official ppc64le wheel; exclusion required unless you enable source builds.
Verified via PyPI that PyNaCl publishes no ppc64le wheels. Keep theplatform_machine != 'ppc64le'marker to avoid install failures. If you need ppc64le support instead, remove this marker and ensure the environment provides system libs (libsodium, libffi) so PyNaCl can build from source.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (3)
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu(3 hunks)runtimes/datascience/ubi9-python-3.12/pylock.toml(36 hunks)runtimes/datascience/ubi9-python-3.12/pyproject.toml(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- runtimes/datascience/ubi9-python-3.12/pyproject.toml
🧰 Additional context used
🧠 Learnings (19)
📓 Common learnings
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-05T17:24:08.616Z
Learning: jiridanek requested PR review for #1521 covering s390x architecture support improvements, demonstrating continued focus on systematic multi-architecture compatibility enhancements in the opendatahub-io/notebooks repository through clean implementation with centralized configuration, proper CI integration, and architecture-aware testing patterns.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/rocm-tensorflow/ubi9-python-3.12/pyproject.toml:75-77
Timestamp: 2025-08-27T15:33:28.871Z
Learning: jiridanek requested GitHub issue creation for multi-architecture environment exploration during PR #2145 review, specifically to investigate architecture-specific environments for ROCm TensorFlow wheel optimization across x86_64, aarch64, ppc64le, and s390x architectures, noting uncertainty about implementation benefits but wanting systematic exploration through issue tracking. Issue #2158 was created with comprehensive analysis covering current limitations, investigation areas, multiple solution options, and clear acceptance criteria.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/pytorch+llmcompressor/ubi9-python-3.12/Dockerfile.cuda:152-159
Timestamp: 2025-08-27T14:49:24.112Z
Learning: jiridanek requested GitHub issue creation for CUDA version alignment in pytorch+llmcompressor runtime during PR #2145 review. Issue #2148 was created addressing the mismatch between Dockerfile CUDA 12.6 and pylock.toml cu124 PyTorch wheels. The issue includes comprehensive problem description covering affected files (runtimes/pytorch+llmcompressor/ubi9-python-3.12/Dockerfile.cuda and pylock.toml), detailed solution with PyTorch index URL update from cu124 to cu126, lock regeneration steps using uv, clear acceptance criteria for wheel alignment verification, and proper context linking to PR #2145 review comment, assigned to jiridanek.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/rocm-tensorflow/ubi9-python-3.12/pyproject.toml:75-77
Timestamp: 2025-08-27T15:33:28.871Z
Learning: jiridanek requested GitHub issue creation for multi-architecture environment exploration during PR #2145 review, specifically to investigate architecture-specific environments for ROCm TensorFlow wheel optimization across x86_64, aarch64, ppc64le, and s390x architectures, noting uncertainty about implementation benefits but wanting systematic exploration through issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:42-52
Timestamp: 2025-07-09T12:29:56.162Z
Learning: jiridanek requested GitHub issue creation for OpenShift client architecture mapping problem affecting 29 Dockerfiles during PR #1320 review. Issue was created with comprehensive analysis covering all affected files using $(uname -m) returning 'aarch64' but OpenShift mirror expecting 'arm64', systematic solution using BuildKit TARGETARCH mapping with proper amd64→x86_64 and arm64→arm64 conversion, detailed acceptance criteria, and implementation guidance, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/pytorch/ubi9-python-3.12/pyproject.toml:25-30
Timestamp: 2025-08-27T15:39:58.693Z
Learning: jiridanek requested GitHub issue creation for missing OS dependencies for database connectors during PR #2145 review. Issue #2160 was created addressing the missing unixODBC and postgresql-libs packages required by pyodbc and psycopg Python dependencies in runtimes/pytorch/ubi9-python-3.12/Dockerfile.cuda. The issue includes comprehensive problem description covering runtime failure risks, detailed solution with Dockerfile updates, clear acceptance criteria for package installation and verification, and proper context linking to PR #2145 review comment, assigned to jiridanek.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/pytorch/ubi9-python-3.12/pyproject.toml:6-11
Timestamp: 2025-08-27T15:45:10.946Z
Learning: jiridanek requested GitHub issue creation for missing CUDA runtime support in pytorch runtime during PR #2145 review. Issue #2161 was created addressing the missing CUDA 12.6 runtime libraries required by cu126 PyTorch wheels in runtimes/pytorch/ubi9-python-3.12/Dockerfile.cuda. The issue includes comprehensive problem description covering current CPU-only base image vs CUDA wheel requirements, three solution options (CUDA-enabled base image, install CUDA libraries, CPU wheels), clear acceptance criteria for GPU acceleration verification, reference to related issue #2148 for CUDA alignment context, and proper context linking to PR #2145 review comment, assigned to jiridanek.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:40-42
Timestamp: 2025-07-04T17:08:02.399Z
Learning: In the opendatahub-io/notebooks repository, when using multi-architecture Dockerfiles with BuildKit, the implicit build argument TARGETARCH is automatically available in the global scope for FROM instructions without explicit declaration. However, if TARGETARCH is used within a build stage, it must be declared explicitly within that stage. The current placement pattern (declaring ARG TARGETARCH after FROM instructions that use it) is correct for modern Docker/Podman/Buildah environments and does not require compatibility with older Docker versions.
Learnt from: atheo89
PR: opendatahub-io/notebooks#1258
File: codeserver/ubi9-python-3.11/Dockerfile.cpu:32-32
Timestamp: 2025-07-07T11:08:48.524Z
Learning: atheo89 requested GitHub issue creation for multi-architecture Dockerfile improvements during PR #1258 review, specifically for enhancing structural consistency across Docker stages, replacing $(uname -m) with ${TARGETARCH} for cross-architecture builds, and adding OCI-compliant metadata labels. Issue #1332 was created with comprehensive problem description, phased implementation approach, detailed acceptance criteria, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:50-50
Timestamp: 2025-07-08T19:30:01.738Z
Learning: jiridanek requested GitHub issue creation for multi-architecture support in ROCm TensorFlow image during PR #1333 review. Issue #1346 was created with comprehensive problem description covering hardcoded x86_64 architecture breaking multi-arch support, detailed impact analysis, three solution options (runtime detection, BuildKit TARGETARCH integration, hybrid approach) with pros/cons analysis, comprehensive acceptance criteria covering core requirements and testing, phased implementation guidance, related files identification, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: jupyter/minimal/ubi9-python-3.11/Dockerfile.cuda:29-38
Timestamp: 2025-07-04T17:07:52.656Z
Learning: In the opendatahub-io/notebooks repository, modern Docker with BuildKit automatically provides build arguments like TARGETARCH in the global scope for FROM instructions, but these arguments must be explicitly declared with ARG statements inside build stages where they will be used. The ARG declaration should be placed within the stage that uses it, not moved to the global scope, as this is the correct pattern for modern Docker/Podman/Buildah environments.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2180
File: base-images/rocm/6.2/ubi9-python-3.12/Dockerfile.rocm:32-34
Timestamp: 2025-08-28T12:43:09.835Z
Learning: Issue #1346 "Multi-architecture support for ROCm TensorFlow runtime image" already covers hardcoded RHEL point release and architecture mapping problems in ROCm Dockerfiles, specifically documenting the hardcoded "rhel/9.4/main/x86_64" pattern in amdgpu repository URLs that breaks multi-architecture builds. This issue should be referenced when encountering similar hardcoded architecture patterns in ROCm base images.
📚 Learning: 2025-08-07T12:41:48.997Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1720
File: jupyter/pytorch+llmcompressor/ubi9-python-3.11/requirements.txt:2659-2680
Timestamp: 2025-08-07T12:41:48.997Z
Learning: For opendatahub-io/notebooks, rpds-py 0.27.0 provides manylinux wheels for Python 3.11 and 3.12 on x86_64 and aarch64, so no Rust build is needed for these platforms. For s390x and ppc64le, wheels are not available, so a Rust build stage or version pinning is required if those images are built.
Applied to files:
runtimes/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-07-07T11:08:48.524Z
Learnt from: atheo89
PR: opendatahub-io/notebooks#1258
File: codeserver/ubi9-python-3.11/Dockerfile.cpu:32-32
Timestamp: 2025-07-07T11:08:48.524Z
Learning: atheo89 requested GitHub issue creation for multi-architecture Dockerfile improvements during PR #1258 review, specifically for enhancing structural consistency across Docker stages, replacing $(uname -m) with ${TARGETARCH} for cross-architecture builds, and adding OCI-compliant metadata labels. Issue #1332 was created with comprehensive problem description, phased implementation approach, detailed acceptance criteria, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-07-09T12:29:56.162Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:42-52
Timestamp: 2025-07-09T12:29:56.162Z
Learning: jiridanek requested GitHub issue creation for OpenShift client architecture mapping problem affecting 29 Dockerfiles during PR #1320 review. Issue was created with comprehensive analysis covering all affected files using $(uname -m) returning 'aarch64' but OpenShift mirror expecting 'arm64', systematic solution using BuildKit TARGETARCH mapping with proper amd64→x86_64 and arm64→arm64 conversion, detailed acceptance criteria, and implementation guidance, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-05T17:24:08.616Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-05T17:24:08.616Z
Learning: jiridanek requested PR review for #1521 covering s390x architecture support improvements, demonstrating continued focus on systematic multi-architecture compatibility enhancements in the opendatahub-io/notebooks repository through clean implementation with centralized configuration, proper CI integration, and architecture-aware testing patterns.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-12T08:40:55.286Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1909
File: runtimes/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:11-15
Timestamp: 2025-08-12T08:40:55.286Z
Learning: jiridanek requested GitHub issue creation for redundant CUDA upgrade optimization during PR #1909 review. Analysis revealed all 14 CUDA Dockerfiles contain redundant `yum upgrade -y` commands in cuda-base stages that execute after base stages already performed comprehensive `dnf upgrade` via pre-upgrade blocks, causing unnecessary CI latency and build inefficiency. Issue includes complete scope analysis with specific line numbers, investigation framework requiring NVIDIA upstream documentation review, multiple solution options, comprehensive acceptance criteria covering systematic testing and performance measurement, and proper context linking to PR #1909 review comment.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-07-04T17:08:02.399Z
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:40-42
Timestamp: 2025-07-04T17:08:02.399Z
Learning: In the opendatahub-io/notebooks repository, when using multi-architecture Dockerfiles with BuildKit, the implicit build argument TARGETARCH is automatically available in the global scope for FROM instructions without explicit declaration. However, if TARGETARCH is used within a build stage, it must be declared explicitly within that stage. The current placement pattern (declaring ARG TARGETARCH after FROM instructions that use it) is correct for modern Docker/Podman/Buildah environments and does not require compatibility with older Docker versions.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-07-08T19:30:01.738Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:50-50
Timestamp: 2025-07-08T19:30:01.738Z
Learning: jiridanek requested GitHub issue creation for multi-architecture support in ROCm TensorFlow image during PR #1333 review. Issue #1346 was created with comprehensive problem description covering hardcoded x86_64 architecture breaking multi-arch support, detailed impact analysis, three solution options (runtime detection, BuildKit TARGETARCH integration, hybrid approach) with pros/cons analysis, comprehensive acceptance criteria covering core requirements and testing, phased implementation guidance, related files identification, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-27T15:33:28.871Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/rocm-tensorflow/ubi9-python-3.12/pyproject.toml:75-77
Timestamp: 2025-08-27T15:33:28.871Z
Learning: jiridanek requested GitHub issue creation for multi-architecture environment exploration during PR #2145 review, specifically to investigate architecture-specific environments for ROCm TensorFlow wheel optimization across x86_64, aarch64, ppc64le, and s390x architectures, noting uncertainty about implementation benefits but wanting systematic exploration through issue tracking.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-27T15:33:28.871Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/rocm-tensorflow/ubi9-python-3.12/pyproject.toml:75-77
Timestamp: 2025-08-27T15:33:28.871Z
Learning: jiridanek requested GitHub issue creation for multi-architecture environment exploration during PR #2145 review, specifically to investigate architecture-specific environments for ROCm TensorFlow wheel optimization across x86_64, aarch64, ppc64le, and s390x architectures, noting uncertainty about implementation benefits but wanting systematic exploration through issue tracking. Issue #2158 was created with comprehensive analysis covering current limitations, investigation areas, multiple solution options, and clear acceptance criteria.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-07-09T12:31:02.033Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:65-66
Timestamp: 2025-07-09T12:31:02.033Z
Learning: jiridanek requested GitHub issue creation for MSSQL repo file hardcoding problem during PR #1320 review. Issue #1363 was created and updated with comprehensive problem description covering hardcoded x86_64 MSSQL repo files breaking multi-architecture builds across 10 affected Dockerfiles (including datascience, CUDA, ROCm, and TrustyAI variants), detailed root cause analysis, three solution options with code examples, clear acceptance criteria for all image types, implementation guidance following established multi-architecture patterns, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-28T12:43:09.835Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2180
File: base-images/rocm/6.2/ubi9-python-3.12/Dockerfile.rocm:32-34
Timestamp: 2025-08-28T12:43:09.835Z
Learning: Issue #1346 "Multi-architecture support for ROCm TensorFlow runtime image" already covers hardcoded RHEL point release and architecture mapping problems in ROCm Dockerfiles, specifically documenting the hardcoded "rhel/9.4/main/x86_64" pattern in amdgpu repository URLs that breaks multi-architecture builds. This issue should be referenced when encountering similar hardcoded architecture patterns in ROCm base images.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-12T08:40:55.286Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1909
File: runtimes/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:11-15
Timestamp: 2025-08-12T08:40:55.286Z
Learning: jiridanek requested GitHub issue creation for redundant CUDA upgrade optimization during PR #1909 review. Issue covers duplicate yum/dnf upgrade commands in cuda-base stages that execute after base stages already performed comprehensive upgrades, causing unnecessary CI latency and build inefficiency across multiple CUDA Dockerfiles. The solution requires investigating NVIDIA upstream documentation requirements before removing redundant upgrades, with systematic testing of all CUDA variants and performance measurement. Issue follows established pattern of comprehensive problem analysis, multiple solution options, detailed acceptance criteria, and proper context linking.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-27T15:20:35.737Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-27T15:20:35.737Z
Learning: jiridanek requested GitHub issue creation for DNF consistency during PR #2145 review, identifying inconsistent yum vs dnf usage across UBI9 Dockerfiles. Issue #2157 was created with comprehensive repository-wide audit strategy, systematic replacement approach, benefits analysis, and clear acceptance criteria for standardizing package manager usage across all UBI9 images, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-29T08:48:55.951Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2185
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:109-117
Timestamp: 2025-08-29T08:48:55.951Z
Learning: In opendatahub-io/notebooks, cleanup consistency should prefer `dnf clean all -y` and avoid manual `rm -rf /var/cache/{dnf,yum}`. For broader refactors (like cache mounts), maintainers prefer to address these systematically under issue #2076 rather than piecemeal in unrelated PRs.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-07-04T10:41:13.061Z
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:34-35
Timestamp: 2025-07-04T10:41:13.061Z
Learning: In the opendatahub-io/notebooks repository, when adapting NVIDIA CUDA Dockerfiles, the project intentionally maintains consistency with upstream NVIDIA patterns even when it might involve potential risks like empty variable expansions in package installation commands. This is considered acceptable because the containers only run on RHEL 9 with known yum/dnf behavior, and upstream consistency is prioritized over defensive coding practices.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-12T08:37:52.783Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1909
File: runtimes/pytorch/ubi9-python-3.11/Dockerfile.cuda:11-15
Timestamp: 2025-08-12T08:37:52.783Z
Learning: In opendatahub-io/notebooks repository Dockerfiles, when cleaning DNF cache after package operations, use only `dnf clean all -y` rather than adding `rm -rf /var/cache/dnf`. The `dnf clean all` command is sufficient and safer as it uses the package manager itself to intelligently remove cached data (downloaded packages, repository metadata, expired transaction info) without bypassing DNF's internal workings. Adding `rm -rf /var/cache/dnf` is redundant and potentially less safe for future DNF compatibility.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-27T15:05:31.656Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu:134-140
Timestamp: 2025-08-27T15:05:31.656Z
Learning: jiridanek requested GitHub issue creation for CUDA wheel optimization in TrustyAI CPU image during PR #2145 review. The CPU Dockerfile currently uses pylock.toml with CUDA-enabled PyTorch wheels (torch==2.6.0+cu126) which was previously discussed with harshad16 and grdryn but deferred. Issue created with comprehensive problem analysis covering unnecessary CUDA wheels in CPU-only image, multiple solution options including lock regeneration and separate CPU/CUDA files, clear acceptance criteria for wheel optimization verification, and proper context linking to PR #2145 review comment.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-19T11:45:12.501Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1998
File: runtimes/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:159-161
Timestamp: 2025-08-19T11:45:12.501Z
Learning: jiridanek requested GitHub issue creation for duplicated micropipenv installation cleanup in pytorch+llmcompressor images during PR #1998 review. Issue addresses redundant installations occurring twice in both affected Dockerfiles: early unpinned install for Pipfile.lock deployment and later pinned install in requirements.txt block. Solution involves removing duplicate installations while maintaining version pinning (1.9.0) and ensuring micropipenv install --dev functionality remains intact. Issue includes comprehensive problem analysis, multiple solution options, detailed acceptance criteria covering build testing and deduplication verification, and proper context linking to PR #1998 review comment.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
🪛 Checkov (3.2.334)
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
[MEDIUM] 19-28: Ensure that packages with untrusted or missing GPG signatures are not used by dnf, tdnf, or yum via the '--nogpgcheck' option
(CKV2_DOCKER_9)
🔇 Additional comments (5)
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu (1)
11-12: Correct TARGETARCH scoping.ARG is declared per-stage where used; this matches the repo’s multi-arch pattern.
runtimes/datascience/ubi9-python-3.12/pylock.toml (4)
440-440: Codeflare gating matches PR objective.This is the only package that should be excluded on ppc64le per the PR description. LGTM.
1801-1801: Align gating of Paramiko and Cryptography
Paramiko has a hard dependency on Cryptography; applying theplatform_machine != 'ppc64le'marker to only one lets dependency resolution succeed locally but masks breakage on ppc64le. Either gate both packages together (so Cryptography still builds where Paramiko is included) or explicitly exclude Paramiko for ppc64le in yourpyproject.tomlrather than hand-editing the lock file.
1354-1354: Exclude ppc64le for msgpack 1.1.1 No manylinux ppc64le wheels are published on PyPI; the existing exclusion marker is correct and msgpack will be built from source on ppc64le.
180-180: Retain the bcrypt exclusion marker for ppc64le
bcrypt 4.3.0 does not publish manylinux wheels for ppc64le on PyPI, so the existingplatform_machine != 'ppc64le'guard must stay to prevent build failures.Likely an incorrect or invalid review comment.
| [[packages]] | ||
| name = "cachetools" | ||
| version = "5.5.2" | ||
| marker = "platform_machine != 'ppc64le'" |
There was a problem hiding this comment.
🛠️ Refactor suggestion
cachetools is pure Python; don’t gate by architecture.
Drop the marker and re-lock.
- marker = "platform_machine != 'ppc64le'"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| marker = "platform_machine != 'ppc64le'" |
🤖 Prompt for AI Agents
In runtimes/datascience/ubi9-python-3.12/pylock.toml around line 262, the entry
currently sets marker = "platform_machine != 'ppc64le'" for cachetools which is
incorrect because cachetools is pure-Python and should not be
architecture-gated; remove the marker line for that dependency and
regenerate/re-lock the lockfile (run the same lock command you used originally)
so the lock reflects the change.
520ae7c to
04f50a9
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (32)
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu (4)
18-28: Drop --nogpgcheck and avoid manual cache rm; rely on dnf clean all.This weakens supply-chain security and manually nukes caches. Use verified GPG keys and dnf’s cleanup.
Apply:
- dnf install -y --nogpgcheck --allowerasing --nobest $PACKAGES && \ - dnf clean all && rm -rf /var/cache/dnf + dnf install -y --allowerasing --nobest $PACKAGES && \ + dnf clean all -y
57-76: OpenBLAS artifact path and NUM_THREADS; add checksum.make -C /openblas will fail because Makefile lives in /openblas/OpenBLAS-. Also lock integrity and avoid huge baked-in threading.
-FROM base AS openblas-builder +FROM base AS openblas-builder @@ -ENV OPENBLAS_VERSION=0.3.30 +ARG OPENBLAS_VERSION @@ -RUN if [ "$TARGETARCH" = "ppc64le" ]; then \ - source /opt/rh/gcc-toolset-13/enable && \ - wget https://github.com/OpenMathLib/OpenBLAS/releases/download/v${OPENBLAS_VERSION}/OpenBLAS-${OPENBLAS_VERSION}.zip && \ - unzip OpenBLAS-${OPENBLAS_VERSION}.zip && cd OpenBLAS-${OPENBLAS_VERSION} && \ - make -j$(nproc) TARGET=POWER9 BINARY=64 USE_OPENMP=1 USE_THREAD=1 NUM_THREADS=120 DYNAMIC_ARCH=1 INTERFACE64=0; \ +RUN if [ "$TARGETARCH" = "ppc64le" ]; then \ + source /opt/rh/gcc-toolset-13/enable && \ + wget -O OpenBLAS-${OPENBLAS_VERSION}.zip https://github.com/OpenMathLib/OpenBLAS/releases/download/v${OPENBLAS_VERSION}/OpenBLAS-${OPENBLAS_VERSION}.zip && \ + unzip OpenBLAS-${OPENBLAS_VERSION}.zip && \ + cd OpenBLAS-${OPENBLAS_VERSION} && \ + make -j"$(nproc)" TARGET=POWER9 BINARY=64 USE_OPENMP=1 USE_THREAD=1 INTERFACE64=0 && \ + cd /root && mv "OpenBLAS-${OPENBLAS_VERSION}" /opt/openblas-src; \ else \ echo "Not ppc64le, skipping OpenBLAS build" && mkdir -p /root/dummy; \ fiOptional: download and verify sha256 before unzip.
123-136: Fix OpenBLAS COPY/install path and guard wheel installs.Current COPY places sources under /openblas/OpenBLAS- but you run make in /openblas (no Makefile). Also guard pip wheel glob.
Apply:
-# Install ppc64le-built wheels if available -COPY --from=openblas-builder /root/OpenBLAS-* /openblas +// Install ppc64le-built wheels if available +COPY --from=openblas-builder /opt/openblas-src /openblas COPY --from=onnx-builder /onnx_wheels /tmp/onnx_wheels RUN if [ "$TARGETARCH" = "ppc64le" ]; then \ echo "Installing ppc64le ONNX wheels and OpenBLAS..." && \ - HOME=/root pip install /tmp/onnx_wheels/*.whl && \ - if [ -d "/openblas" ] && [ "$(ls -A /openblas 2>/dev/null)" ]; then \ - PREFIX=/usr/local make -C /openblas install; \ + if compgen -G "/tmp/onnx_wheels/*.whl" > /dev/null; then \ + HOME=/root pip install /tmp/onnx_wheels/*.whl; \ + fi && \ + if [ -d "/openblas" ]; then \ + PREFIX=/usr/local make -C /openblas install; \ fi && rm -rf /openblas /tmp/onnx_wheels; \ else \ echo "Skipping architecture-specific wheel installs for (${TARGETARCH})" && \ rm -rf /tmp/wheels /openblas /tmp/onnx_wheels; \ fi
143-155: Export GRPC env; avoid out-of-lock ml-dtypes to retain reproducibility.Bare assignment doesn’t reach pip; and installing outside the lock breaks hermeticity and may fail on ppc64le.
if [ "$TARGETARCH" = "ppc64le" ]; then \ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig; \ export LD_LIBRARY_PATH=/usr/local/lib64:/usr/local/lib:/usr/lib64:/usr/lib:$LD_LIBRARY_PATH; \ - GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1 && \ - pip install ml-dtypes && \ + export GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1; \ + # Move ml-dtypes into pyproject with a 'platform_machine == "ppc64le"' marker and regenerate pylock instead of ad-hoc install. uv pip install --strict --no-deps --no-cache --no-config --no-progress --verify-hashes --compile-bytecode --index-strategy=unsafe-best-match --requirements=./pylock.toml; \Run to verify locking and env usage:
#!/bin/bash set -euo pipefail # Confirm ml-dtypes is locked (should appear with a ppc64le marker) grep -nH "ml-dtypes" runtimes/datascience/ubi9-python-3.12/pyproject.toml || true grep -nH "ml-dtypes" runtimes/datascience/ubi9-python-3.12/pylock.toml || true # Show the GRPC env usage line nl -ba runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu | sed -n '140,160p'runtimes/datascience/ubi9-python-3.12/pylock.toml (28)
2631-2631: ray gate is redundant if codeflare is excludedRemove ad-hoc gating; transitive resolution will drop ray on ppc64le.
- marker = "platform_machine != 'ppc64le'"
262-262: cachetools is pure Python; remove arch marker (duplicate of earlier feedback)Drop the marker and re-lock.
- marker = "platform_machine != 'ppc64le'"
275-275: cffi marker uses leaking “or”; likely unnecessaryIf cffi is needed, keep it un-gated (ppc64le wheels generally exist). Remove the marker or fix to “and” and move to pyproject.
- marker = "python_full_version < '3.14' or platform_machine != 'ppc64le'" + # remove marker; handle in pyproject if truly required
447-447: colorful is pure Python; drop markerRemove the arch gate and re-lock.
- marker = "platform_machine != 'ppc64le'"
622-622: distlib/durationpy are pure Python; remove gatesDelete markers and re-lock.
- marker = "platform_machine != 'ppc64le'"Also applies to: 635-635
660-660: filelock is pure Python; remove gate (and avoid unrelated bumps nearby)Drop the marker; also avoid adjacent unrelated version churn—re-lock from pyproject.
- marker = "platform_machine != 'ppc64le'"
731-731: frozenlist “or” leak; don’t gate in lockRemove marker or fix to “and” in pyproject and re-lock.
- marker = "python_full_version == '3.12.*' or platform_machine != 'ppc64le'" + # remove marker from lock; handle in pyproject if needed
842-870: Pure-Python google libs gated; grpcio handling
- fsspec, google-api-core, google-auth, googleapis-common-protos: remove markers.
- grpcio lacks ppc64le wheels; if excluded, do it in pyproject; else add a build path.
- marker = "platform_machine != 'ppc64le'" + # remove marker; handle via pyproject if necessary
934-934: invoke is pure Python; drop marker- marker = "platform_machine != 'ppc64le'"
965-965: ipywidgets is core UX; don’t exclude on ppc64leRemove marker; otherwise widgets break.
- marker = "platform_machine != 'ppc64le'"
1026-1026: jupyterlab-widgets should match ipywidgets; drop marker- marker = "platform_machine != 'ppc64le'"
1146-1156: kubernetes/markdown-it-py are pure Python; remove gates- marker = "platform_machine != 'ppc64le'"
1294-1294: mdurl is pure Python; drop gate- marker = "platform_machine != 'ppc64le'"
1420-1420: multidict “or” leak; remove or move markerFix to “and” or drop marker; best handled in pyproject.
- marker = "python_full_version == '3.12.*' or platform_machine != 'ppc64le'" + # remove marker from lock; handle in pyproject if needed
1661-1661: oauthlib is pure Python; remove arch gate- marker = "platform_machine != 'ppc64le'"
1714-1728: opencensus/opencensus-context/openshift-client are pure Python; drop gates- marker = "platform_machine != 'ppc64le'"
1945-1953: prometheus-client is pure Python; drop gate. prompt-toolkit bump is out-of-scopeRemove marker; revert version to main by re-locking.
- marker = "platform_machine != 'ppc64le'"
1958-1958: propcache “or” leakFix logic or remove marker and move to pyproject.
- marker = "python_full_version == '3.12.*' or platform_machine != 'ppc64le'" + marker = "python_full_version == '3.12.*' and platform_machine != 'ppc64le'"
2063-2063: proto-plus is pure Python; remove arch gate- marker = "python_full_version >= '3.6' and platform_machine != 'ppc64le'"
2120-2120: py-spy: declare in pyproject with marker; don’t edit lock directly
Example pyproject entry (if truly desired):
- "py-spy==0.4.1; python_full_version >= '3.12' and platform_machine != 'ppc64le'"
Then re-lock.
2185-2201: pyasn1 / pyasn1-modules are pure Python; pycparser “or” leak
- Remove gates from pyasn1*.
- Fix or remove pycparser marker.
- marker = "platform_machine != 'ppc64le'" - marker = "python_full_version < '3.14' or platform_machine != 'ppc64le'" + # remove markers; handle in pyproject if necessary
2253-2253: pydantic supports ppc64le via pydantic-core; remove gateDrop the arch marker and re-lock.
- marker = "platform_machine != 'ppc64le'"
2674-2681: requests-oauthlib and rich are pure Python; drop gatesRemove markers and re-lock.
- marker = "platform_machine != 'ppc64le'"
2849-2849: rsa is pure Python; remove gate- marker = "platform_machine != 'ppc64le'"
2968-2976: smart-open is OS-independent; remove gate. soupsieve bump out-of-scopeDrop marker; revert soupsieve to main via re-lock.
- marker = "platform_machine != 'ppc64le'"
3053-3053: virtualenv/websocket-client are pure Python; remove gatesDelete markers and re-lock.
- marker = "platform_machine != 'ppc64le'"Also applies to: 3072-3072
3180-3180: yarl “or” leak; don’t gate in lockRemove marker or fix to “and” in pyproject and re-lock.
- marker = "python_full_version == '3.12.*' or platform_machine != 'ppc64le'" + # remove marker from lock; handle in pyproject if needed
7-20: Global: avoid editing pylock; move arch logic to pyproject and re-lockThis lock shows widespread, inconsistent ppc64le gating and several leaking "or" markers. Only codeflare-sdk was intended to be excluded per PR scope. Please:
- Encode any necessary per-arch exclusions in runtimes/datascience/ubi9-python-3.12/pyproject.toml (PEP 508 markers).
- Regenerate pylock.toml with the documented uv command.
This also reverts unrelated version bumps (fonttools, soupsieve, prompt-toolkit).
🧹 Nitpick comments (1)
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu (1)
81-101: Make ONNX build more reproducible and faster.Use shallow clone of the tag and avoid unnecessary history; consider pinning the tag’s commit SHA.
-RUN if [ "$TARGETARCH" = "ppc64le" ]; then \ - source /opt/rh/gcc-toolset-13/enable && \ - git clone --recursive https://github.com/onnx/onnx.git && \ - cd onnx && git checkout v${ONNX_VERSION} && \ - git submodule update --init --recursive && \ +RUN if [ "$TARGETARCH" = "ppc64le" ]; then \ + source /opt/rh/gcc-toolset-13/enable && \ + git clone --branch "v${ONNX_VERSION}" --depth 1 --recursive https://github.com/onnx/onnx.git && \ + cd onnx && \ pip install -r requirements.txt && \ export CMAKE_ARGS="-DPython3_EXECUTABLE=$(which python3.12)" && \ pip wheel . -w /onnx_wheels; \If desired, verify commit:
git -C onnx rev-parse HEADand compare to a known SHA.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (3)
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu(3 hunks)runtimes/datascience/ubi9-python-3.12/pylock.toml(36 hunks)runtimes/datascience/ubi9-python-3.12/pyproject.toml(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- runtimes/datascience/ubi9-python-3.12/pyproject.toml
🧰 Additional context used
🧠 Learnings (24)
📓 Common learnings
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-05T17:24:08.616Z
Learning: jiridanek requested PR review for #1521 covering s390x architecture support improvements, demonstrating continued focus on systematic multi-architecture compatibility enhancements in the opendatahub-io/notebooks repository through clean implementation with centralized configuration, proper CI integration, and architecture-aware testing patterns.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/rocm-tensorflow/ubi9-python-3.12/pyproject.toml:75-77
Timestamp: 2025-08-27T15:33:28.871Z
Learning: jiridanek requested GitHub issue creation for multi-architecture environment exploration during PR #2145 review, specifically to investigate architecture-specific environments for ROCm TensorFlow wheel optimization across x86_64, aarch64, ppc64le, and s390x architectures, noting uncertainty about implementation benefits but wanting systematic exploration through issue tracking. Issue #2158 was created with comprehensive analysis covering current limitations, investigation areas, multiple solution options, and clear acceptance criteria.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/pytorch+llmcompressor/ubi9-python-3.12/Dockerfile.cuda:152-159
Timestamp: 2025-08-27T14:49:24.112Z
Learning: jiridanek requested GitHub issue creation for CUDA version alignment in pytorch+llmcompressor runtime during PR #2145 review. Issue #2148 was created addressing the mismatch between Dockerfile CUDA 12.6 and pylock.toml cu124 PyTorch wheels. The issue includes comprehensive problem description covering affected files (runtimes/pytorch+llmcompressor/ubi9-python-3.12/Dockerfile.cuda and pylock.toml), detailed solution with PyTorch index URL update from cu124 to cu126, lock regeneration steps using uv, clear acceptance criteria for wheel alignment verification, and proper context linking to PR #2145 review comment, assigned to jiridanek.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/rocm-tensorflow/ubi9-python-3.12/pyproject.toml:75-77
Timestamp: 2025-08-27T15:33:28.871Z
Learning: jiridanek requested GitHub issue creation for multi-architecture environment exploration during PR #2145 review, specifically to investigate architecture-specific environments for ROCm TensorFlow wheel optimization across x86_64, aarch64, ppc64le, and s390x architectures, noting uncertainty about implementation benefits but wanting systematic exploration through issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/pytorch/ubi9-python-3.12/pyproject.toml:25-30
Timestamp: 2025-08-27T15:39:58.693Z
Learning: jiridanek requested GitHub issue creation for missing OS dependencies for database connectors during PR #2145 review. Issue #2160 was created addressing the missing unixODBC and postgresql-libs packages required by pyodbc and psycopg Python dependencies in runtimes/pytorch/ubi9-python-3.12/Dockerfile.cuda. The issue includes comprehensive problem description covering runtime failure risks, detailed solution with Dockerfile updates, clear acceptance criteria for package installation and verification, and proper context linking to PR #2145 review comment, assigned to jiridanek.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:42-52
Timestamp: 2025-07-09T12:29:56.162Z
Learning: jiridanek requested GitHub issue creation for OpenShift client architecture mapping problem affecting 29 Dockerfiles during PR #1320 review. Issue was created with comprehensive analysis covering all affected files using $(uname -m) returning 'aarch64' but OpenShift mirror expecting 'arm64', systematic solution using BuildKit TARGETARCH mapping with proper amd64→x86_64 and arm64→arm64 conversion, detailed acceptance criteria, and implementation guidance, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1720
File: jupyter/pytorch+llmcompressor/ubi9-python-3.11/requirements.txt:2659-2680
Timestamp: 2025-08-07T12:41:48.997Z
Learning: For opendatahub-io/notebooks, rpds-py 0.27.0 provides manylinux wheels for Python 3.11 and 3.12 on x86_64 and aarch64, so no Rust build is needed for these platforms. For s390x and ppc64le, wheels are not available, so a Rust build stage or version pinning is required if those images are built.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/pytorch/ubi9-python-3.12/pyproject.toml:6-11
Timestamp: 2025-08-27T15:45:10.946Z
Learning: jiridanek requested GitHub issue creation for missing CUDA runtime support in pytorch runtime during PR #2145 review. Issue #2161 was created addressing the missing CUDA 12.6 runtime libraries required by cu126 PyTorch wheels in runtimes/pytorch/ubi9-python-3.12/Dockerfile.cuda. The issue includes comprehensive problem description covering current CPU-only base image vs CUDA wheel requirements, three solution options (CUDA-enabled base image, install CUDA libraries, CPU wheels), clear acceptance criteria for GPU acceleration verification, reference to related issue #2148 for CUDA alignment context, and proper context linking to PR #2145 review comment, assigned to jiridanek.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:40-42
Timestamp: 2025-07-04T17:08:02.399Z
Learning: In the opendatahub-io/notebooks repository, when using multi-architecture Dockerfiles with BuildKit, the implicit build argument TARGETARCH is automatically available in the global scope for FROM instructions without explicit declaration. However, if TARGETARCH is used within a build stage, it must be declared explicitly within that stage. The current placement pattern (declaring ARG TARGETARCH after FROM instructions that use it) is correct for modern Docker/Podman/Buildah environments and does not require compatibility with older Docker versions.
Learnt from: atheo89
PR: opendatahub-io/notebooks#1258
File: codeserver/ubi9-python-3.11/Dockerfile.cpu:32-32
Timestamp: 2025-07-07T11:08:48.524Z
Learning: atheo89 requested GitHub issue creation for multi-architecture Dockerfile improvements during PR #1258 review, specifically for enhancing structural consistency across Docker stages, replacing $(uname -m) with ${TARGETARCH} for cross-architecture builds, and adding OCI-compliant metadata labels. Issue #1332 was created with comprehensive problem description, phased implementation approach, detailed acceptance criteria, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: jupyter/minimal/ubi9-python-3.11/Dockerfile.cuda:29-38
Timestamp: 2025-07-04T17:07:52.656Z
Learning: In the opendatahub-io/notebooks repository, modern Docker with BuildKit automatically provides build arguments like TARGETARCH in the global scope for FROM instructions, but these arguments must be explicitly declared with ARG statements inside build stages where they will be used. The ARG declaration should be placed within the stage that uses it, not moved to the global scope, as this is the correct pattern for modern Docker/Podman/Buildah environments.
📚 Learning: 2025-07-04T17:08:02.399Z
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:40-42
Timestamp: 2025-07-04T17:08:02.399Z
Learning: In the opendatahub-io/notebooks repository, when using multi-architecture Dockerfiles with BuildKit, the implicit build argument TARGETARCH is automatically available in the global scope for FROM instructions without explicit declaration. However, if TARGETARCH is used within a build stage, it must be declared explicitly within that stage. The current placement pattern (declaring ARG TARGETARCH after FROM instructions that use it) is correct for modern Docker/Podman/Buildah environments and does not require compatibility with older Docker versions.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-07-07T11:08:48.524Z
Learnt from: atheo89
PR: opendatahub-io/notebooks#1258
File: codeserver/ubi9-python-3.11/Dockerfile.cpu:32-32
Timestamp: 2025-07-07T11:08:48.524Z
Learning: atheo89 requested GitHub issue creation for multi-architecture Dockerfile improvements during PR #1258 review, specifically for enhancing structural consistency across Docker stages, replacing $(uname -m) with ${TARGETARCH} for cross-architecture builds, and adding OCI-compliant metadata labels. Issue #1332 was created with comprehensive problem description, phased implementation approach, detailed acceptance criteria, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-07-04T17:07:52.656Z
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: jupyter/minimal/ubi9-python-3.11/Dockerfile.cuda:29-38
Timestamp: 2025-07-04T17:07:52.656Z
Learning: In the opendatahub-io/notebooks repository, modern Docker with BuildKit automatically provides build arguments like TARGETARCH in the global scope for FROM instructions, but these arguments must be explicitly declared with ARG statements inside build stages where they will be used. The ARG declaration should be placed within the stage that uses it, not moved to the global scope, as this is the correct pattern for modern Docker/Podman/Buildah environments.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-07-09T12:29:56.162Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:42-52
Timestamp: 2025-07-09T12:29:56.162Z
Learning: jiridanek requested GitHub issue creation for OpenShift client architecture mapping problem affecting 29 Dockerfiles during PR #1320 review. Issue was created with comprehensive analysis covering all affected files using $(uname -m) returning 'aarch64' but OpenShift mirror expecting 'arm64', systematic solution using BuildKit TARGETARCH mapping with proper amd64→x86_64 and arm64→arm64 conversion, detailed acceptance criteria, and implementation guidance, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpuruntimes/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-08-28T12:43:09.835Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2180
File: base-images/rocm/6.2/ubi9-python-3.12/Dockerfile.rocm:32-34
Timestamp: 2025-08-28T12:43:09.835Z
Learning: Issue #1346 "Multi-architecture support for ROCm TensorFlow runtime image" already covers hardcoded RHEL point release and architecture mapping problems in ROCm Dockerfiles, specifically documenting the hardcoded "rhel/9.4/main/x86_64" pattern in amdgpu repository URLs that breaks multi-architecture builds. This issue should be referenced when encountering similar hardcoded architecture patterns in ROCm base images.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-28T12:42:23.404Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2180
File: .tekton/odh-base-image-cuda-py312-ubi9-pull-request.yaml:36-39
Timestamp: 2025-08-28T12:42:23.404Z
Learning: Konflux build system in opendatahub-io/notebooks repository requires "linux/x86_64" platform identifier format for Tekton PipelineRun build-platforms parameter, not the OCI-standard "linux/amd64". This is consistently used across all .tekton/ pipeline files and enforced by scripts/generate_pull_request_pipelineruns.py type definitions. Docker/buildah contexts use "linux/amd64" while Konflux/Tekton contexts use "linux/x86_64".
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-12T08:40:55.286Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1909
File: runtimes/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:11-15
Timestamp: 2025-08-12T08:40:55.286Z
Learning: jiridanek requested GitHub issue creation for redundant CUDA upgrade optimization during PR #1909 review. Analysis revealed all 14 CUDA Dockerfiles contain redundant `yum upgrade -y` commands in cuda-base stages that execute after base stages already performed comprehensive `dnf upgrade` via pre-upgrade blocks, causing unnecessary CI latency and build inefficiency. Issue includes complete scope analysis with specific line numbers, investigation framework requiring NVIDIA upstream documentation review, multiple solution options, comprehensive acceptance criteria covering systematic testing and performance measurement, and proper context linking to PR #1909 review comment.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-12T08:40:55.286Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1909
File: runtimes/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:11-15
Timestamp: 2025-08-12T08:40:55.286Z
Learning: jiridanek requested GitHub issue creation for redundant CUDA upgrade optimization during PR #1909 review. Issue covers duplicate yum/dnf upgrade commands in cuda-base stages that execute after base stages already performed comprehensive upgrades, causing unnecessary CI latency and build inefficiency across multiple CUDA Dockerfiles. The solution requires investigating NVIDIA upstream documentation requirements before removing redundant upgrades, with systematic testing of all CUDA variants and performance measurement. Issue follows established pattern of comprehensive problem analysis, multiple solution options, detailed acceptance criteria, and proper context linking.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-27T15:20:35.737Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-27T15:20:35.737Z
Learning: jiridanek requested GitHub issue creation for DNF consistency during PR #2145 review, identifying inconsistent yum vs dnf usage across UBI9 Dockerfiles. Issue #2157 was created with comprehensive repository-wide audit strategy, systematic replacement approach, benefits analysis, and clear acceptance criteria for standardizing package manager usage across all UBI9 images, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-29T08:48:55.985Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2185
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:109-117
Timestamp: 2025-08-29T08:48:55.985Z
Learning: In opendatahub-io/notebooks, cleanup consistency should prefer `dnf clean all -y` and avoid manual `rm -rf /var/cache/{dnf,yum}`. For broader refactors (like cache mounts), maintainers prefer to address these systematically under issue #2076 rather than piecemeal in unrelated PRs.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-07-04T10:41:13.061Z
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:34-35
Timestamp: 2025-07-04T10:41:13.061Z
Learning: In the opendatahub-io/notebooks repository, when adapting NVIDIA CUDA Dockerfiles, the project intentionally maintains consistency with upstream NVIDIA patterns even when it might involve potential risks like empty variable expansions in package installation commands. This is considered acceptable because the containers only run on RHEL 9 with known yum/dnf behavior, and upstream consistency is prioritized over defensive coding practices.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-12T08:37:52.783Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1909
File: runtimes/pytorch/ubi9-python-3.11/Dockerfile.cuda:11-15
Timestamp: 2025-08-12T08:37:52.783Z
Learning: In opendatahub-io/notebooks repository Dockerfiles, when cleaning DNF cache after package operations, use only `dnf clean all -y` rather than adding `rm -rf /var/cache/dnf`. The `dnf clean all` command is sufficient and safer as it uses the package manager itself to intelligently remove cached data (downloaded packages, repository metadata, expired transaction info) without bypassing DNF's internal workings. Adding `rm -rf /var/cache/dnf` is redundant and potentially less safe for future DNF compatibility.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-27T15:05:31.656Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu:134-140
Timestamp: 2025-08-27T15:05:31.656Z
Learning: jiridanek requested GitHub issue creation for CUDA wheel optimization in TrustyAI CPU image during PR #2145 review. The CPU Dockerfile currently uses pylock.toml with CUDA-enabled PyTorch wheels (torch==2.6.0+cu126) which was previously discussed with harshad16 and grdryn but deferred. Issue created with comprehensive problem analysis covering unnecessary CUDA wheels in CPU-only image, multiple solution options including lock regeneration and separate CPU/CUDA files, clear acceptance criteria for wheel optimization verification, and proper context linking to PR #2145 review comment.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-29T09:06:34.580Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-29T09:06:34.580Z
Learning: In opendatahub-io/notebooks, `dnf clean all` should be used without the `-y` flag as it's a cleanup operation that doesn't require user confirmation. The repository currently has inconsistent usage patterns with some Dockerfiles using `dnf clean all -y` and others using `dnf clean all`, but the `-y` is unnecessary for cleanup operations.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-08-29T08:46:47.973Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2185
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:133-137
Timestamp: 2025-08-29T08:46:47.973Z
Learning: In opendatahub-io/notebooks, maintainer preference is to batch package-manager cache/cleanup changes under Issue #2076 (“Use caching in our Dockerfiles, Podman has decent support, will make local builds faster”) rather than applying piecemeal fixes in individual PRs (e.g., removing rm -rf cache paths); future suggestions should align with #2076’s repository-wide approach.
Applied to files:
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-07-24T12:01:45.188Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-24T12:01:45.188Z
Learning: jiridanek requested verification of 2024.2 tag package versions against corresponding Pipfiles during PR #1496 review. The analysis revealed that 2024.2 tags contain intentionally frozen older versions (N-1 behavior) while the current PR correctly updates only the N (latest) tags to match Python 3.11 Pipfiles, demonstrating proper understanding of the repository's N-1 version freezing policy.
Applied to files:
runtimes/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-08-06T15:33:47.175Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#968
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:17-18
Timestamp: 2025-08-06T15:33:47.175Z
Learning: During PR #968 review, CodeRabbit initially incorrectly identified 1 legitimate micropipenv usage in jupyter/tensorflow/ubi9-python-3.12/Dockerfile.cuda when analyzing Python 3.12 images for unused dependencies. Upon jiridanek's request for re-verification, comprehensive analysis revealed all 15 Python 3.12 Dockerfiles install micropipenv but none actually use it, making the cleanup scope 100% unnecessary installations with no exceptions to handle.
Applied to files:
runtimes/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-08-27T15:33:28.871Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/rocm-tensorflow/ubi9-python-3.12/pyproject.toml:75-77
Timestamp: 2025-08-27T15:33:28.871Z
Learning: jiridanek requested GitHub issue creation for multi-architecture environment exploration during PR #2145 review, specifically to investigate architecture-specific environments for ROCm TensorFlow wheel optimization across x86_64, aarch64, ppc64le, and s390x architectures, noting uncertainty about implementation benefits but wanting systematic exploration through issue tracking.
Applied to files:
runtimes/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-08-05T17:24:08.616Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-05T17:24:08.616Z
Learning: jiridanek requested PR review for #1521 covering s390x architecture support improvements, demonstrating continued focus on systematic multi-architecture compatibility enhancements in the opendatahub-io/notebooks repository through clean implementation with centralized configuration, proper CI integration, and architecture-aware testing patterns.
Applied to files:
runtimes/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-08-27T15:33:28.871Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/rocm-tensorflow/ubi9-python-3.12/pyproject.toml:75-77
Timestamp: 2025-08-27T15:33:28.871Z
Learning: jiridanek requested GitHub issue creation for multi-architecture environment exploration during PR #2145 review, specifically to investigate architecture-specific environments for ROCm TensorFlow wheel optimization across x86_64, aarch64, ppc64le, and s390x architectures, noting uncertainty about implementation benefits but wanting systematic exploration through issue tracking. Issue #2158 was created with comprehensive analysis covering current limitations, investigation areas, multiple solution options, and clear acceptance criteria.
Applied to files:
runtimes/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-07-20T20:47:36.509Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1396
File: runtimes/tensorflow/ubi9-python-3.12/Dockerfile.cuda:124-127
Timestamp: 2025-07-20T20:47:36.509Z
Learning: jiridanek identified that ARM64 wheels for h5py 3.14.0 are available on PyPI but being ignored due to AMD64-only dependency locking with --platform=linux/amd64. This causes unnecessary hdf5-devel package installation in ARM64 TensorFlow images when the ARM64 wheel h5py-3.14.0-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl could be used instead. The Pipfile.lock only contains 2 hashes for h5py, confirming limited platform consideration during lock generation.
Applied to files:
runtimes/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-07-01T10:41:56.419Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatahub-io/notebooks. They run `pipenv lock` inside UBI9 containers with specific platform arguments (`--platform=linux/amd64 --python-version 3.12`) to avoid host OS dependency conflicts when generating Pipfile.lock files.
Applied to files:
runtimes/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-08-07T12:41:48.997Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1720
File: jupyter/pytorch+llmcompressor/ubi9-python-3.11/requirements.txt:2659-2680
Timestamp: 2025-08-07T12:41:48.997Z
Learning: For opendatahub-io/notebooks, rpds-py 0.27.0 provides manylinux wheels for Python 3.11 and 3.12 on x86_64 and aarch64, so no Rust build is needed for these platforms. For s390x and ppc64le, wheels are not available, so a Rust build stage or version pinning is required if those images are built.
Applied to files:
runtimes/datascience/ubi9-python-3.12/pylock.toml
🪛 Checkov (3.2.334)
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu
[MEDIUM] 19-28: Ensure that packages with untrusted or missing GPG signatures are not used by dnf, tdnf, or yum via the '--nogpgcheck' option
(CKV2_DOCKER_9)
🔇 Additional comments (12)
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu (3)
11-12: Correct ARG scoping for TARGETARCH.Declaring ARG inside each stage is the right pattern with BuildKit; FROM-time and in-stage uses are handled correctly.
107-107: ARG TARGETARCH correctly re-declared in runtime stage.
160-161: User switch back to 1001 at end looks good.runtimes/datascience/ubi9-python-3.12/pylock.toml (9)
180-180: bcrypt: decide policy; don’t gate in the lockbcrypt has C-ext; if you need to exclude on ppc64le, declare it in pyproject (with justification) and re-lock. Don’t hand-edit pylock.
Would you like me to propose a pyproject marker and run a verification script to list direct/indirect dependents?
440-440: codeflare-sdk gating is the only intended change—LGTMThis aligns with PR scope to skip codeflare on ppc64le.
538-538: cryptography: choose one path and make it consistent
- Preferred: support cryptography on ppc64le (Rust toolchain in builder or pin to a wheel version), then drop downstream gates (e.g., paramiko).
- If you must exclude: also gate all dependents (paramiko, pyopenssl, etc.) via pyproject, not the lock.
I can draft a minimal builder stage and affected dependency list—want that?
666-726: fonttools version bump is out-of-scopeRevert to the version on main by re-locking from pyproject; do not curate wheel lists by hand.
1354-1354: msgpack: don’t gate in lock; decide in pyprojectIf unsupported on ppc64le for your stack, mark in pyproject; otherwise remove this gate and re-lock.
1801-1801: paramiko depends on cryptography; align with chosen approachIf you include cryptography, remove this gate; if you exclude cryptography, keep this but move to pyproject and audit other dependents.
2135-2135: pyarrow (no ppc64le wheels): move exclusion to pyproject, not lockEither add a build path or exclude via pyproject and re-lock.
2379-2379: PyNaCl (C-ext): don’t gate in lock; decide in pyprojectEither add libsodium/build path or exclude in pyproject with rationale; then re-lock.
3085-3092: Verify wheel availability and adjust gating
- Confirm that
widgetsnbextension==4.0.14ships a ppc64le wheel on PyPI before removing itsmarker.- Move the
wrapt==1.17.3exclusion intopyproject.toml(instead of editing the lock) and then regenerate the lock.
Comment on lines
30
to
49
| RUN if [ "$TARGETARCH" = "ppc64le" ]; then \ | ||
| echo 'export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/' >> /etc/profile.d/ppc64le.sh && \ | ||
| echo 'export LD_LIBRARY_PATH=/usr/local/lib64:/usr/local/lib:/usr/lib64:/usr/lib:$LD_LIBRARY_PATH' >> /etc/profile.d/ppc64le.sh && \ | ||
| echo 'export OPENBLAS_VERSION=0.3.30' >> /etc/profile.d/ppc64le.sh && \ | ||
| echo 'export ONNX_VERSION=1.19.0' >> /etc/profile.d/ppc64le.sh && \ | ||
| echo 'export PATH="$HOME/.cargo/bin:$PATH"' >> /etc/profile.d/ppc64le.sh; \ | ||
| echo 'export GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1' >> /etc/profile.d/ppc64le.sh; \ | ||
| fi |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Avoid baking build-only env into /etc/profile; centralize versions as ARG/ENV.
profile.d is not sourced in non-login build steps; you already export where needed. Also OPENBLAS_VERSION/ONNX_VERSION are duplicated here and in builder stages. DRY this with top-level ARG/ENV and remove the profile echoes for versions and GRPC var.
-RUN if [ "$TARGETARCH" = "ppc64le" ]; then \
- echo 'export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/' >> /etc/profile.d/ppc64le.sh && \
- echo 'export LD_LIBRARY_PATH=/usr/local/lib64:/usr/local/lib:/usr/lib64:/usr/lib:$LD_LIBRARY_PATH' >> /etc/profile.d/ppc64le.sh && \
- echo 'export OPENBLAS_VERSION=0.3.30' >> /etc/profile.d/ppc64le.sh && \
- echo 'export ONNX_VERSION=1.19.0' >> /etc/profile.d/ppc64le.sh && \
- echo 'export PATH="$HOME/.cargo/bin:$PATH"' >> /etc/profile.d/ppc64le.sh; \
- echo 'export GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1' >> /etc/profile.d/ppc64le.sh; \
- fi
+RUN if [ "$TARGETARCH" = "ppc64le" ]; then \
+ echo 'export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/' >> /etc/profile.d/ppc64le.sh && \
+ echo 'export LD_LIBRARY_PATH=/usr/local/lib64:/usr/local/lib:/usr/lib64:/usr/lib:$LD_LIBRARY_PATH' >> /etc/profile.d/ppc64le.sh && \
+ echo 'export PATH="$HOME/.cargo/bin:$PATH"' >> /etc/profile.d/ppc64le.sh; \
+ fiAdditionally (outside this hunk), define once and reuse:
# Near the top of the file (base stage)
ARG OPENBLAS_VERSION=0.3.30
ARG ONNX_VERSION=1.19.0Then in builder stages, replace per-stage ENV with ARG OPENBLAS_VERSION / ARG ONNX_VERSION.
🤖 Prompt for AI Agents
In runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu around lines 30-37, the
Dockerfile is writing build-only environment variables (OPENBLAS_VERSION,
ONNX_VERSION, GRPC_PYTHON_BUILD_SYSTEM_OPENSSL and other PATH/LD vars) into
/etc/profile.d which is unnecessary and unreliable for build steps and
duplicates definitions in builder stages; remove the echo >>
/etc/profile.d/ppc64le.sh lines for versions and GRPC var, instead declare ARG
OPENBLAS_VERSION and ARG ONNX_VERSION once near the top of the Dockerfile (base
stage) and use ARG OPENBLAS_VERSION / ARG ONNX_VERSION in downstream builder
stages, keep only runtime-needed PATH/LD exports if required but prefer ENV in
appropriate stage, and ensure any cargo PATH or LD_LIBRARY_PATH needed during
build is exported locally in RUN steps rather than persisted to /etc/profile.d.
There was a problem hiding this comment.
@coderabbitai create github issue, good point
There was a problem hiding this comment.
🧩 Analysis chain
</shell_scripts>
@jiridanek I've created a comprehensive GitHub issue addressing the environment variable management problems in the datascience runtime Dockerfile. The issue covers the duplication of version constants, unnecessary persistence of build-only variables to /etc/profile.d, and provides a clear refactoring path with centralized ARG definitions.
The issue includes detailed problem analysis, multiple solution options, and specific implementation guidance to improve the build reliability and maintainability of the ppc64le architecture support.
/\_/\
( o.o )
> ^ <
🏁 Script executed:
#!/bin/bash
# Create GitHub issue for Dockerfile environment variable refactoring
gh issue create \
--title "Refactor datascience runtime Dockerfile environment variable management for ppc64le builds" \
--body "## Problem Description
The current datascience runtime Dockerfile (runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu) has several issues with environment variable management for ppc64le builds:
### Issues Identified
1. **Build-only variables written to /etc/profile.d**: Lines 30-37 write build-time variables like OPENBLAS_VERSION, ONNX_VERSION, and GRPC_PYTHON_BUILD_SYSTEM_OPENSSL to /etc/profile.d/ppc64le.sh, which persists them unnecessarily in the runtime image.
2. **Variable duplication**: OPENBLAS_VERSION=0.3.30 is defined both in /etc/profile.d/ppc64le.sh (line 33) and separately as ENV in the openblas-builder stage (line 165).
3. **Unreliable sourcing**: /etc/profile.d scripts are not sourced in non-login build contexts, making the approach unreliable for build steps.
4. **Missing DRY principle**: Version constants are duplicated across multiple stages instead of being centralized.
### Current Code (Lines 30-37)
\`\`\`dockerfile
RUN if [ \"\$TARGETARCH\" = \"ppc64le\" ]; then \
echo 'export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/' >> /etc/profile.d/ppc64le.sh && \
echo 'export LD_LIBRARY_PATH=/usr/local/lib64:/usr/local/lib:/usr/lib64:/usr/lib:\$LD_LIBRARY_PATH' >> /etc/profile.d/ppc64le.sh && \
echo 'export OPENBLAS_VERSION=0.3.30' >> /etc/profile.d/ppc64le.sh && \
echo 'export ONNX_VERSION=1.19.0' >> /etc/profile.d/ppc64le.sh && \
echo 'export PATH=\"\$HOME/.cargo/bin:\$PATH\"' >> /etc/profile.d/ppc64le.sh && \
echo 'export GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1' >> /etc/profile.d/ppc64le.sh; \
fi
\`\`\`
## Impact Analysis
- **Build reliability**: Build-time variables may not be available when needed due to profile.d sourcing issues
- **Image bloat**: Unnecessary persistence of build-only variables in runtime image
- **Maintenance overhead**: Version updates require changes in multiple locations
- **Code clarity**: Duplicated definitions reduce maintainability
## Solution Options
### Option 1: Centralized ARG/ENV approach (Recommended)
- Define version constants as ARG near the top of Dockerfile
- Use ARG inheritance in downstream stages
- Remove /etc/profile.d writes for build-only variables
- Keep only runtime-needed PATH/LD exports
### Option 2: Stage-specific ENV with build-time exports
- Use ENV in appropriate stages for versions
- Export variables locally in RUN steps where needed
- Minimize /etc/profile.d usage
### Option 3: Hybrid approach
- Centralize versions as ARG
- Use local exports for build steps
- Selective /etc/profile.d for genuine runtime needs
## Acceptance Criteria
- [ ] Version constants (OPENBLAS_VERSION, ONNX_VERSION) defined once as ARG
- [ ] Build-only variables not persisted to /etc/profile.d
- [ ] All builder stages use centralized version definitions
- [ ] Runtime-needed environment variables properly configured
- [ ] Build functionality preserved across all architectures
- [ ] Image size impact measured and documented
## Implementation Guidance
1. **Add centralized version ARGs**:
\`\`\`dockerfile
ARG OPENBLAS_VERSION=0.3.30
ARG ONNX_VERSION=1.19.0
\`\`\`
2. **Update builder stages to use ARGs**:
\`\`\`dockerfile
FROM cpu-base AS openblas-builder
ARG OPENBLAS_VERSION
# Remove: ENV OPENBLAS_VERSION=0.3.30
\`\`\`
3. **Minimize /etc/profile.d usage**:
\`\`\`dockerfile
RUN if [ \"\$TARGETARCH\" = \"ppc64le\" ]; then \
echo 'export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/' >> /etc/profile.d/ppc64le.sh && \
echo 'export LD_LIBRARY_PATH=/usr/local/lib64:/usr/local/lib:/usr/lib64:/usr/lib:\$LD_LIBRARY_PATH' >> /etc/profile.d/ppc64le.sh; \
fi
\`\`\`
4. **Use local exports in build steps**:
\`\`\`dockerfile
RUN export GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1 && pip install ...
\`\`\`
## Related Files
- runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu (primary)
## Context
This issue was identified during PR #2215 review for ppc64le architecture support: https://github.com/opendatahub-io/notebooks/pull/2215#discussion_r2310300016" \
--assignee jiridanek
Length of output: 4265
Perfect! I've successfully created issue #2311 addressing the Dockerfile environment variable management problems: #2311
The issue comprehensively covers:
- The specific problems with writing build-only variables to /etc/profile.d
- Variable duplication between stages (OPENBLAS_VERSION, ONNX_VERSION)
- Unreliable sourcing in build contexts
- Clear refactoring guidance with centralized ARG/ENV approach
- Detailed acceptance criteria and implementation steps
This will help systematically improve the ppc64le build architecture and maintain cleaner Dockerfile practices across the project.
/\_/\
( ^.^ )
> ^ <
Happy to help!
✏️ Learnings added
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T12:10:50.840Z
Learning: jiridanek requested GitHub issue creation for Dockerfile environment variable refactoring during PR #2215 review. Issue addresses build-only variables (OPENBLAS_VERSION, ONNX_VERSION, GRPC_PYTHON_BUILD_SYSTEM_OPENSSL) being unnecessarily written to /etc/profile.d/ppc64le.sh in runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu, causing variable duplication across stages, unreliable sourcing in non-login build contexts, and violation of DRY principles. The issue includes comprehensive problem description covering affected lines 30-37, detailed impact analysis of build reliability and maintenance overhead, three solution options with centralized ARG/ENV approach as recommended, clear acceptance criteria for version centralization and build-only variable cleanup, and specific implementation guidance with code examples, continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T12:10:50.840Z
Learning: jiridanek requested GitHub issue creation for Dockerfile environment variable refactoring during PR #2215 review. Issue #2311 was created addressing build-only variables (OPENBLAS_VERSION, ONNX_VERSION, GRPC_PYTHON_BUILD_SYSTEM_OPENSSL) being unnecessarily written to /etc/profile.d/ppc64le.sh in runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu, causing variable duplication across stages, unreliable sourcing in non-login build contexts, and violation of DRY principles. The issue includes comprehensive problem description covering affected lines 30-37, detailed impact analysis of build reliability and maintenance overhead, three solution options with centralized ARG/ENV approach as recommended, clear acceptance criteria for version centralization and build-only variable cleanup, and specific implementation guidance with code examples, assigned to jiridanek, continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
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.
🧠 Learnings used
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:40-42
Timestamp: 2025-07-04T17:08:02.399Z
Learning: In the opendatahub-io/notebooks repository, when using multi-architecture Dockerfiles with BuildKit, the implicit build argument TARGETARCH is automatically available in the global scope for FROM instructions without explicit declaration. However, if TARGETARCH is used within a build stage, it must be declared explicitly within that stage. The current placement pattern (declaring ARG TARGETARCH after FROM instructions that use it) is correct for modern Docker/Podman/Buildah environments and does not require compatibility with older Docker versions.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:34-35
Timestamp: 2025-07-04T10:41:13.061Z
Learning: In the opendatahub-io/notebooks repository, when adapting NVIDIA CUDA Dockerfiles, the project intentionally maintains consistency with upstream NVIDIA patterns even when it might involve potential risks like empty variable expansions in package installation commands. This is considered acceptable because the containers only run on RHEL 9 with known yum/dnf behavior, and upstream consistency is prioritized over defensive coding practices.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T11:27:31.022Z
Learning: jiridanek requested GitHub issue creation for build toolchain optimization in datascience runtime during PR #2215 review. Issue #2308 was created addressing unnecessary build dependencies (gcc-toolset-13, cmake, ninja-build, rust, cargo) in final runtime image for ppc64le architecture, covering comprehensive problem analysis with specific line numbers, multiple solution options for builder-only toolchains, clear acceptance criteria for size reduction and security improvement, detailed implementation guidance for package segregation, and proper context linking to PR #2215 review comment, continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1909
File: runtimes/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:11-15
Timestamp: 2025-08-12T08:40:55.286Z
Learning: jiridanek requested GitHub issue creation for redundant CUDA upgrade optimization during PR #1909 review. Analysis revealed all 14 CUDA Dockerfiles contain redundant `yum upgrade -y` commands in cuda-base stages that execute after base stages already performed comprehensive `dnf upgrade` via pre-upgrade blocks, causing unnecessary CI latency and build inefficiency. Issue includes complete scope analysis with specific line numbers, investigation framework requiring NVIDIA upstream documentation review, multiple solution options, comprehensive acceptance criteria covering systematic testing and performance measurement, and proper context linking to PR #1909 review comment.
Learnt from: atheo89
PR: opendatahub-io/notebooks#1258
File: codeserver/ubi9-python-3.11/Dockerfile.cpu:32-32
Timestamp: 2025-07-07T11:08:48.524Z
Learning: atheo89 requested GitHub issue creation for multi-architecture Dockerfile improvements during PR #1258 review, specifically for enhancing structural consistency across Docker stages, replacing $(uname -m) with ${TARGETARCH} for cross-architecture builds, and adding OCI-compliant metadata labels. Issue #1332 was created with comprehensive problem description, phased implementation approach, detailed acceptance criteria, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1909
File: runtimes/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:11-15
Timestamp: 2025-08-12T08:40:55.286Z
Learning: jiridanek requested GitHub issue creation for redundant CUDA upgrade optimization during PR #1909 review. Issue covers duplicate yum/dnf upgrade commands in cuda-base stages that execute after base stages already performed comprehensive upgrades, causing unnecessary CI latency and build inefficiency across multiple CUDA Dockerfiles. The solution requires investigating NVIDIA upstream documentation requirements before removing redundant upgrades, with systematic testing of all CUDA variants and performance measurement. Issue follows established pattern of comprehensive problem analysis, multiple solution options, detailed acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-pytorch/ubi9-python-3.12/utils/bootstrapper.py:1-769
Timestamp: 2025-07-08T19:35:49.482Z
Learning: jiridanek requested GitHub issue creation for bootstrapper code duplication problem in runtimes/rocm-pytorch/ubi9-python-3.12/utils/bootstrapper.py during PR #1333 review. After an initial failed attempt, issue #1349 was successfully created with comprehensive problem description covering maintenance overhead and consistency risks from duplicate implementations across 5 Python 3.12 runtime environments, four solution options (symlinks, import-based, template-based, direct shared import) with pros/cons analysis, clear acceptance criteria for consolidation and maintainability, step-by-step implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/rocm-tensorflow/ubi9-python-3.12/pyproject.toml:75-77
Timestamp: 2025-08-27T15:33:28.871Z
Learning: jiridanek requested GitHub issue creation for multi-architecture environment exploration during PR #2145 review, specifically to investigate architecture-specific environments for ROCm TensorFlow wheel optimization across x86_64, aarch64, ppc64le, and s390x architectures, noting uncertainty about implementation benefits but wanting systematic exploration through issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:42-52
Timestamp: 2025-07-09T12:29:56.162Z
Learning: jiridanek requested GitHub issue creation for OpenShift client architecture mapping problem affecting 29 Dockerfiles during PR #1320 review. Issue was created with comprehensive analysis covering all affected files using $(uname -m) returning 'aarch64' but OpenShift mirror expecting 'arm64', systematic solution using BuildKit TARGETARCH mapping with proper amd64→x86_64 and arm64→arm64 conversion, detailed acceptance criteria, and implementation guidance, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/pytorch/ubi9-python-3.12/Dockerfile.cuda:17-25
Timestamp: 2025-07-09T08:07:30.628Z
Learning: jiridanek requested GitHub issue creation for oc client installation permission problem in PyTorch CUDA runtime Dockerfile during PR #1333 review. Issue #1356 was created with comprehensive problem description covering USER 1001 permission conflicts with root-owned /opt/app-root/bin directory, detailed impact analysis of build failures and non-executable binaries, current problematic code snippet, complete solution with user switching approach, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/kustomize/base/kustomization.yaml:8-12
Timestamp: 2025-07-08T19:09:48.746Z
Learning: jiridanek requested GitHub issue creation for misleading CUDA prefix in TrustyAI image tags during PR #1306 review. Issue was created with comprehensive problem description covering both Python 3.11 and 3.12 versions, repository pattern analysis showing correct vs incorrect naming, clear solution with code examples, detailed acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/kustomize/base/kustomization.yaml:8-12
Timestamp: 2025-07-08T19:09:48.746Z
Learning: jiridanek requested GitHub issue creation for misleading CUDA prefix in TrustyAI image tags during PR #1306 review, affecting both Python 3.11 and 3.12 versions. Issue #1338 was created with comprehensive problem description covering both affected images, repository pattern analysis comparing correct vs incorrect naming conventions, clear solution with code examples, detailed acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-05T17:24:08.616Z
Learning: jiridanek requested PR review for #1521 covering s390x architecture support improvements, demonstrating continued focus on systematic multi-architecture compatibility enhancements in the opendatahub-io/notebooks repository through clean implementation with centralized configuration, proper CI integration, and architecture-aware testing patterns.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:50-50
Timestamp: 2025-07-08T19:30:01.738Z
Learning: jiridanek requested GitHub issue creation for multi-architecture support in ROCm TensorFlow image during PR #1333 review. Issue #1346 was created with comprehensive problem description covering hardcoded x86_64 architecture breaking multi-arch support, detailed impact analysis, three solution options (runtime detection, BuildKit TARGETARCH integration, hybrid approach) with pros/cons analysis, comprehensive acceptance criteria covering core requirements and testing, phased implementation guidance, related files identification, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. The automated issue creation failed despite appearing successful, so comprehensive issue content was provided for manual creation covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/rocm-tensorflow/ubi9-python-3.12/pyproject.toml:75-77
Timestamp: 2025-08-27T15:33:28.871Z
Learning: jiridanek requested GitHub issue creation for multi-architecture environment exploration during PR #2145 review, specifically to investigate architecture-specific environments for ROCm TensorFlow wheel optimization across x86_64, aarch64, ppc64le, and s390x architectures, noting uncertainty about implementation benefits but wanting systematic exploration through issue tracking. Issue #2158 was created with comprehensive analysis covering current limitations, investigation areas, multiple solution options, and clear acceptance criteria.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/tensorflow/ubi9-python-3.12/Dockerfile.cuda:38-38
Timestamp: 2025-07-08T19:30:20.513Z
Learning: jiridanek requested GitHub issue creation for multi-architecture support in TensorFlow CUDA runtime image during PR #1333 review. Issue was created with comprehensive problem description covering hardcoded NVARCH limitation, multiple solution options using TARGETARCH build argument with architecture mapping, acceptance criteria for multi-architecture builds, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2185
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:109-117
Timestamp: 2025-08-29T08:48:55.985Z
Learning: jiridanek prefers to implement systematic cleanup improvements through dedicated GitHub issues (like #2076) rather than applying individual point fixes during PR reviews, maintaining consistency with their established pattern of comprehensive code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/pytorch+llmcompressor/ubi9-python-3.12/Dockerfile.cuda:152-159
Timestamp: 2025-08-27T14:49:24.112Z
Learning: jiridanek requested GitHub issue creation for CUDA version alignment in pytorch+llmcompressor runtime during PR #2145 review. Issue #2148 was created addressing the mismatch between Dockerfile CUDA 12.6 and pylock.toml cu124 PyTorch wheels. The issue includes comprehensive problem description covering affected files (runtimes/pytorch+llmcompressor/ubi9-python-3.12/Dockerfile.cuda and pylock.toml), detailed solution with PyTorch index URL update from cu124 to cu126, lock regeneration steps using uv, clear acceptance criteria for wheel alignment verification, and proper context linking to PR #2145 review comment, assigned to jiridanek.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1179
File: jupyter/utils/install_pandoc.sh:1-1
Timestamp: 2025-09-05T07:46:50.781Z
Learning: jiridanek requested GitHub issue creation during PR #1179 review to explore installing Pandoc from EPEL repository for ppc64le architecture as an alternative to building from source, noting that EPEL packages are acceptable unlike CentOS Stream in red-hat-data-services/notebooks. Issue #2281 was successfully created with comprehensive problem description covering build complexity concerns, multiple solution options, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/pytorch/ubi9-python-3.12/pyproject.toml:25-30
Timestamp: 2025-08-27T15:39:58.693Z
Learning: jiridanek requested GitHub issue creation for missing OS dependencies for database connectors during PR #2145 review. Issue #2160 was created addressing the missing unixODBC and postgresql-libs packages required by pyodbc and psycopg Python dependencies in runtimes/pytorch/ubi9-python-3.12/Dockerfile.cuda. The issue includes comprehensive problem description covering runtime failure risks, detailed solution with Dockerfile updates, clear acceptance criteria for package installation and verification, and proper context linking to PR #2145 review comment, assigned to jiridanek.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1179
File: jupyter/utils/install_pandoc.sh:1-1
Timestamp: 2025-09-05T07:46:50.781Z
Learning: jiridanek requested GitHub issue creation during PR #1179 review to explore installing Pandoc from EPEL repository for ppc64le architecture as an alternative to building from source, noting that EPEL packages are acceptable unlike CentOS Stream in red-hat-data-services/notebooks, continuing the established pattern of systematic infrastructure improvements through comprehensive issue tracking.
|
@jiridanek, Could you please review this PR |
jiridanek
reviewed
Aug 29, 2025
| PACKAGES="mesa-libGL skopeo libxcrypt-compat"; \ | ||
| fi && \ | ||
| echo "Installing: $PACKAGES" && \ | ||
| dnf install -y --nogpgcheck --allowerasing --nobest $PACKAGES && \ |
There was a problem hiding this comment.
--nogpgcheck --allowerasing --nobest
@AaruniAggarwal why?
There was a problem hiding this comment.
Hi @jiridanek , Thanks for reviewing the PR.
I added these flags to handle dependency conflicts during package installation.
There was a problem hiding this comment.
what conflicts were there? any downgrades that can be causing problems for us down the line? how come there are packages where gpg check does not pass?
There was a problem hiding this comment.
I added these flags just to make sure none of the package installs fail during the build. I haven’t tried running the install without them yet, but I’ll give it a try and update you with the results.
There was a problem hiding this comment.
Hi @jiridanek , thanks for reviewing the code.
I have incorporated the suggested changes and pushed the updated code.
Thanks
jiridanek
reviewed
Aug 29, 2025
|
I have made similar changes here: red-hat-data-services#1511 |
|
All the Images are also building fine in konflux. |
jiridanek
force-pushed
the
runtime-datascience-ppc64le
branch
from
56a3784 to
4f9a662
Compare
Signed-off-by: AaruniAggarwal <[email protected]> # Conflicts: # runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu # runtimes/datascience/ubi9-python-3.12/pylock.toml # runtimes/datascience/ubi9-python-3.12/pyproject.toml
jiridanek
force-pushed
the
runtime-datascience-ppc64le
branch
from
4f9a662 to
9e78fb4
Compare
8 tasks
|
@AaruniAggarwal: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
jiridanek
changed the title
Open
6 tasks
|
and, successful build
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces ppc64le (IBM Power) support for the runtime-datascience notebook images.
Changes will not impact other platforms (x86_64, arm64, etc.)
Able to build image locally.
Skipping codeflare-sdk on ppc64le by updating pyproject.toml.
So, Regenerated pylock.toml using following command:
uv pip compile pyproject.toml --output-file pylock.toml --format pylock.toml --generate-hashes --emit-index-url --python-version=3.12 --python-platform linux --no-annotateSummary by CodeRabbit
New Features
Improvements
Dependency Updates