ppc64le: implement datascience jupyter image build on ppc64le (#2406) #2460
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
WalkthroughAdds ppc64le and s390x build targets to CI and pipeline generation, expands the datascience Py3.12 UBI9 Dockerfile with multi-arch pyarrow and Power-specific builder stages (ONNX, OpenBLAS), and updates many Python package markers to exclude ppc64le alongside s390x. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✨ 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. Comment |
github-actions
bot
added
the
review-requested
jiridanek
force-pushed
the
datascience-jupyter-multiarch
branch
from
4c03270 to
d76226b
Compare
jiridanek
commented
Sep 15, 2025
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (5)
scripts/generate_pull_request_pipelineruns.py (1)
146-146: Approve as-is; optional: extract PPC64LE component set and alphabetize.Confirmed "odh-workbench-jupyter-datascience-cpu-py312-ubi9" is present at scripts/generate_pull_request_pipelineruns.py:146. Consider this minimal refactor:
@@ - if component in [ - "odh-workbench-codeserver-datascience-cpu-py312-ubi9", - "odh-workbench-jupyter-datascience-cpu-py312-ubi9", - "odh-workbench-jupyter-minimal-cpu-py312-ubi9", - "odh-pipeline-runtime-minimal-cpu-py312-ubi9", - "odh-pipeline-runtime-datascience-cpu-py312-ubi9", - ]: - build_platforms.extend(["linux/ppc64le"]) + PPC64LE_COMPONENTS = { + "odh-pipeline-runtime-datascience-cpu-py312-ubi9", + "odh-pipeline-runtime-minimal-cpu-py312-ubi9", + "odh-workbench-codeserver-datascience-cpu-py312-ubi9", + "odh-workbench-jupyter-datascience-cpu-py312-ubi9", + "odh-workbench-jupyter-minimal-cpu-py312-ubi9", + } + if component in PPC64LE_COMPONENTS: + build_platforms.append("linux/ppc64le")jupyter/datascience/ubi9-python-3.12/pylock.toml (1)
2492-2543: opencensus/opentelemetry/openshift-client suite: be cautious with broad exclusions.These are pure-Python and can affect telemetry/observability/cluster integration. Confirm they’re only required by ppc64le‑excluded stacks; otherwise this could drop functionality on ppc64le images.
ci/cached-builds/gen_gha_matrix_jobs.py (1)
84-87: Enum shape inconsistency vs arm64/s390xarm64/s390x enums support an “ONLY/only” mode; ppc64le omits it. For symmetry and future-proofing of the CLI/logic, consider adding an ONLY option even if unused immediately.
Apply:
-class Ppc64leImages(enum.Enum): - EXCLUDE = "exclude" - INCLUDE = "include" +class Ppc64leImages(enum.Enum): + EXCLUDE = "exclude" + INCLUDE = "include" + ONLY = "only"jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu (2)
213-213: OpenBLAS: Avoid hardcoding NUM_THREADS=120Hardcoding the library’s default runtime thread count to 120 is risky and may hurt performance/latency on smaller nodes. Let OpenBLAS pick defaults or set via env at runtime.
Apply:
- make -j$(nproc) TARGET=POWER9 BINARY=64 USE_OPENMP=1 USE_THREAD=1 NUM_THREADS=120 DYNAMIC_ARCH=1 INTERFACE64=0 + make -j$(nproc) TARGET=POWER9 BINARY=64 USE_OPENMP=1 USE_THREAD=1 DYNAMIC_ARCH=1 INTERFACE64=0If a fixed default is needed, prefer controlling via
ENV OMP_NUM_THREADSorOPENBLAS_NUM_THREADSin the final image, not at build time.
250-255: Duplicate ARG TARGETARCH in stage
ARG TARGETARCHis declared twice in this stage. Keep a single declaration to avoid confusion.Apply:
FROM jupyter-minimal AS jupyter-datascience ARG TARGETARCH @@ ARG DATASCIENCE_SOURCE_CODE=jupyter/datascience/ubi9-python-3.12 ARG OPENBLAS_VERSION=0.3.30 -ARG TARGETARCH
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
.tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-pull-request.yaml(1 hunks)ci/cached-builds/gen_gha_matrix_jobs.py(4 hunks)jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu(4 hunks)jupyter/datascience/ubi9-python-3.12/pylock.toml(19 hunks)jupyter/datascience/ubi9-python-3.12/pyproject.toml(1 hunks)scripts/generate_pull_request_pipelineruns.py(1 hunks)
🧰 Additional context used
🧠 Learnings (26)
📓 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#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T11:27:31.040Z
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#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#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T12:10:50.856Z
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.
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.856Z
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#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/kustomize/base/service.yaml:5-15
Timestamp: 2025-07-02T18:59:15.788Z
Learning: jiridanek creates targeted GitHub issues for specific test quality improvements identified during PR reviews in opendatahub-io/notebooks. Issue #1268 demonstrates this by converting a review comment about insufficient tf2onnx conversion test validation into a comprehensive improvement plan with clear acceptance criteria, code examples, and ROCm-specific context.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2317
File: codeserver/ubi9-python-3.12/get_code_server_rpm.sh:31-37
Timestamp: 2025-09-05T13:16:48.754Z
Learning: jiridanek requested GitHub issue creation for build tools installation unification across builder images during PR #2317 review. Issue #2322 was created addressing inconsistent build dependency management patterns across different builder images, proposing multiple solution approaches including Development Tools group installation, centralized configuration, and layered approaches, with comprehensive acceptance criteria covering auditing, standardization, regression prevention, and multi-architecture support (x86_64, ppc64le, aarch64, s390x), continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
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.
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.
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#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.
📚 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:
.tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-pull-request.yamlscripts/generate_pull_request_pipelineruns.py
📚 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:
.tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-pull-request.yaml
📚 Learning: 2025-09-05T11:27:31.040Z
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.040Z
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.
Applied to files:
.tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-pull-request.yamljupyter/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:
.tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-pull-request.yaml
📚 Learning: 2025-09-10T21:01:46.464Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-09-10T21:01:46.464Z
Learning: jiridanek requested GitHub issue creation for banner comment documentation update in codeserver/ubi9-python-3.12/get_code_server_rpm.sh during PR #2356 review. Issue #2395 was created to update outdated banner comment that only mentioned ppc64le support when script now builds RPMs for amd64, arm64, and ppc64le architectures, with specific diff showing the required changes from lines 4-8, continuing the established pattern of systematic documentation improvements through detailed issue tracking.
Applied to files:
.tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-pull-request.yaml
📚 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:
.tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-pull-request.yaml
📚 Learning: 2025-09-05T12:25:09.719Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2227
File: codeserver/ubi9-python-3.12/Dockerfile.cpu:122-123
Timestamp: 2025-09-05T12:25:09.719Z
Learning: jiridanek requested GitHub issue creation for Docker multi-stage synchronization improvement in codeserver/ubi9-python-3.12/Dockerfile.cpu during PR #2227 review. The issue addresses sentinel file pattern using /tmp/control copied to /dev/null for stage coordination between rpm-base, whl-cache, and codeserver stages, proposing semantic improvements with descriptive file names, inline documentation, and elimination of /dev/null hack while maintaining multi-architecture build functionality for ppc64le support.
Applied to files:
.tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-pull-request.yamljupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T12:10:50.856Z
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.856Z
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.
Applied to files:
.tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-pull-request.yamljupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T10:05:35.575Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1513
File: runtimes/datascience/ubi9-python-3.12/pylock.toml:180-180
Timestamp: 2025-09-05T10:05:35.575Z
Learning: In Python lock files for the datascience runtime, both bcrypt and paramiko packages are excluded from s390x platform using the marker "platform_machine != 's390x'" due to compatibility issues on IBM System z mainframe architecture.
Applied to files:
jupyter/datascience/ubi9-python-3.12/pyproject.tomljupyter/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-08-29T15:18:43.229Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2215
File: runtimes/datascience/ubi9-python-3.12/pylock.toml:110-110
Timestamp: 2025-08-29T15:18:43.229Z
Learning: The file `runtimes/datascience/ubi9-python-3.12/pylock.toml` is a generated file and should not be edited directly. Changes should be made to the source pyproject.toml file instead.
Applied to files:
jupyter/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:
jupyter/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-09-02T07:55:31.824Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2233
File: tests/test_main.py:46-56
Timestamp: 2025-09-02T07:55:31.824Z
Learning: jiridanek deferred a suggestion for enhanced pyproject.toml/pylock.toml validation in PR #2233 tests/test_main.py. The current test implementation works fine, but future enhancements may need: name normalization using canonicalize_name() to handle case/separator mismatches, environment markers evaluation to skip dependencies not applicable to the image's Python/OS, and handling non-PEP440 versions from VCS/URL dependencies by checking if locked_version exists before asserting specifier.contains(). The deferred implementation includes evaluating markers against image environment (_env = {"python_version": python, "sys_platform": "linux", "platform_system": "Linux"}) and using tomllib.load() with binary mode for consistency.
Applied to files:
jupyter/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-08-29T15:18:43.229Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2215
File: runtimes/datascience/ubi9-python-3.12/pylock.toml:110-110
Timestamp: 2025-08-29T15:18:43.229Z
Learning: When uv compiles dependencies with platform restrictions (like `platform_machine != 'ppc64le'`), it automatically propagates these markers to transitive dependencies in the generated lock files. This is expected behavior and doesn't require manual intervention in source files.
Applied to files:
jupyter/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-09-12T08:38:43.732Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/pylock.toml:105-111
Timestamp: 2025-09-12T08:38:43.732Z
Learning: The pylock.toml file in jupyter/datascience/ubi9-python-3.12/ is autogenerated by uv and should not be manually edited. Changes should be made to the source files like pyproject.toml instead.
Applied to files:
jupyter/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-08-27T14:49:24.112Z
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.
Applied to files:
jupyter/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-09-12T23:07:03.779Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1875
File: jupyter/datascience/ubi9-python-3.12/pylock.toml:0-0
Timestamp: 2025-09-12T23:07:03.779Z
Learning: During PR #1875 review, jiridanek identified boto3/botocore/s3transfer dependency triplet misalignment across ubi9-python-3.12 images and requested GitHub issue creation. Issue #2447 was created to track systematic alignment of mixed versions (boto3: 1.37.38 vs 1.40.20, botocore: 1.37.38 vs 1.40.20, s3transfer: 0.11.5 vs 0.13.1) with target alignment to boto3==1.40.20, botocore==1.40.20, s3transfer==0.13.1 across all ubi9-python-3.12 pylock.toml files.
Applied to files:
jupyter/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:
jupyter/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-09-05T12:10:50.856Z
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.856Z
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.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-12T08:27:00.439Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:232-249
Timestamp: 2025-09-12T08:27:00.439Z
Learning: jiridanek requested GitHub issue creation for Rust toolchain availability during s390x builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2432 review. The issue addresses PATH availability problems where Rust/cargo installed in cpu-base stage at /opt/.cargo/bin may not be accessible during uv pip install step in jupyter-datascience stage, proposing three solution approaches: immediate environment variable fix, builder stage pattern following codeserver approach, and ENV declaration fix, with comprehensive acceptance criteria covering build reliability, multi-architecture compatibility, and alignment with established patterns, continuing the systematic infrastructure improvement tracking methodology.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-12T08:27:00.439Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:232-249
Timestamp: 2025-09-12T08:27:00.439Z
Learning: jiridanek requested GitHub issue creation for Rust toolchain availability during s390x builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2432 review. Issue #2435 was created addressing PATH availability problems where Rust/cargo installed in cpu-base stage at /opt/.cargo/bin may not be accessible during uv pip install step in jupyter-datascience stage, proposing three solution approaches: immediate environment variable fix, builder stage pattern following codeserver approach, and ENV declaration fix, with comprehensive acceptance criteria covering build reliability, multi-architecture compatibility, and alignment with established patterns, continuing the systematic infrastructure improvement tracking methodology.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T12:29:07.819Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2227
File: codeserver/ubi9-python-3.12/Dockerfile.cpu:218-218
Timestamp: 2025-09-05T12:29:07.819Z
Learning: jiridanek requested GitHub issue creation for uv multi-stage Docker build architectural investigation during PR #2227 review. The current implementation uses a three-stage build with whl-cache stage for wheel building/caching, base stage for OS setup, and final codeserver stage for offline installation using --offline flag and cache mounts. The pattern separates build phase (internet access, build tools) from install phase (offline, faster) while supporting multi-architecture builds (x86_64, ppc64le) with sentinel file coordination using /tmp/control files.
Applied to files:
jupyter/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:
jupyter/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:
jupyter/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:
jupyter/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:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
🪛 GitHub Actions: Code static analysis
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
[warning] 219-219: Hadolint: Unexpected issue: unexpected '#' at line 219; expecting a new line followed by the next instruction
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: build (jupyter-datascience-ubi9-python-3.12, 3.12, linux/ppc64le, false) / build
- GitHub Check: build (jupyter-datascience-ubi9-python-3.12, 3.12, linux/amd64, false) / build
- GitHub Check: Red Hat Konflux / odh-workbench-jupyter-datascience-cpu-py312-ubi9-on-pull-request
🔇 Additional comments (27)
.tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-pull-request.yaml (1)
39-39: Approve — add linux/ppc64le to build-platforms (Konflux/Tekton naming)Verified: .tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-pull-request.yaml contains "linux/x86_64" and "linux/ppc64le"; no "linux/amd64" found in .tekton/*pull-request.yaml.
jupyter/datascience/ubi9-python-3.12/pyproject.toml (1)
20-20: Align pylock with pyproject: ensure codeflare-sdk is excluded on ppc64le/s390xpyproject.toml already excludes codeflare-sdk for ppc64le/s390x (line 20) but pylock.toml contains a codeflare-sdk entry (name = "codeflare-sdk" at ~line 550). Regenerate/update the lock so the package entry carries the same platform marker or is omitted for those arches, and add a short inline comment linking to the tracking issue.
- Actions:
- Update/regenerate jupyter/datascience/ubi9-python-3.12/pylock.toml so codeflare-sdk has the same marker or is removed for ppc64le/s390x (current occurrence at ~line 550).
- Add a short rationale comment above the dependency in jupyter/datascience/ubi9-python-3.12/pyproject.toml (example):
Excluded on ppc64le/s390x pending upstream support; track re-enable in issue XYZ.
- "codeflare-sdk~=0.31.0; platform_machine != 'ppc64le' and platform_machine != 's390x'",
jupyter/datascience/ubi9-python-3.12/pylock.toml (19)
108-108: aiohttp-cors: verify this exclusion is transitive-only.This is pure-Python; exclusion should come only from a transitive dep path that’s disabled on ppc64le. Please confirm nothing else on ppc64le requires it.
225-225: bcrypt: exclusion on ppc64le looks reasonable.Avoids Rust/native build on ppc64le. Ensure no remaining packages pull it in on ppc64le.
552-552: codeflare-sdk: consistent with ppc64le opt‑out.This aligns with broader PR gating for ppc64le. No further action.
565-565: colorful: double‑check necessity of exclusion.Pure-Python. Please confirm it’s only required by a package already excluded on ppc64le (e.g., ray/codeflare), not by anything that remains.
757-757: distlib: verify marker origin.Pure-Python and commonly used via virtualenv/pip tooling. Ensure the exclusion is purely transitive and doesn’t affect ppc64le runtime needs.
812-812: filelock: verify transitive‑only exclusion.Pure-Python; validate nothing on ppc64le still needs it.
1205-1205: grpcio: excluding on ppc64le is sensible.Native build can be problematic; gating via marker is fine if generated by uv.
1348-1348: invoke: confirm not needed on ppc64le paths.Pure-Python. Please validate it’s only brought by excluded stacks on ppc64le.
1708-1708: markdown-it-py: verify exclusion doesn’t remove a shared utility.Pure-Python; ensure no ppc64le code path still consumes it.
1855-1855: mdurl: same concern—pure‑Python utility.Confirm it’s transitive-only from excluded stacks.
2048-2048: msgpack: validate dependency graph on ppc64le.Often pulled by ray; if that’s the sole reason, fine. Otherwise ensure no remaining package on ppc64le needs it.
2620-2620: paramiko: mirrors bcrypt gate—OK.Consistent with s390x precedent; acceptable if SSH features aren’t needed on ppc64le.
2958-2958: py-spy: exclusion is appropriate.No ppc64le wheels; Rust build would be heavy. Good to gate.
3562-3562: ray: exclusion is expected.Ray doesn’t support ppc64le; marker is correct if generated by uv.
3641-3641: rich: verify it’s not needed elsewhere on ppc64le.Pure-Python and widely used. Please confirm exclusion is transitive-only.
4004-4004: smart-open: confirm transitive-only.Pure-Python; ensure no ppc64le code path still uses it (e.g., S3 helpers).
4376-4376: virtualenv: double-check impact.Tooling dependency; exclusion should be safe if not used in-image on ppc64le.
4648-4648: wrapt: verify provenance of the marker.Often a compiled extension; if exclusion is due to lack of wheels and only needed by gated stacks, fine. Otherwise reassess.
105-111: Resolved — pylock markers match pyproject (no action required).
rg output shows the same platform marker in jupyter/datascience/ubi9-python-3.12/pyproject.toml (e.g. the codeflare-sdk entry) and identical markers across pylock.toml entries, so the changes are consistent with a re-lock.ci/cached-builds/gen_gha_matrix_jobs.py (2)
33-36: LGTM: Good start list for ppc64le-compatible targetsThe initial allowlist looks correct for enabling ppc64le on minimal and datascience images.
Please confirm there are no other Makefile targets already ppc64le-ready (e.g., runtime variants) that should be added now to avoid follow-up PR churn.
167-169: LGTM: Conditional ppc64le inclusion matches the compatibility allowlistThis mirrors the arm64/s390x approach and keeps non-compatible targets out of the ppc64le matrix.
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu (4)
271-274: LGTM: unixODBC/headers inclusionThese are commonly needed for DB clients and match the Power-specific build flow. Cleanup of caches is correct.
281-282: LGTM: PKG_CONFIG_PATH for /usr/localRequired for the OpenBLAS install into /usr/local; avoids link failures later.
291-306: Nice: Power-only artifact copy + gated installThe pattern of copying from builder stages and gating by TARGETARCH is clean and keeps non-Power paths fast.
Please confirm the ONNX wheel is built against Python 3.12 ABI (manylinux/plat tag) matching the final image.
160-175: Fix hadolint heredoc parse failure — replace RUN heredocs with explicit bash -c RUNsHadolint's parser fails on RUN heredocs in this Dockerfile; replace the heredoc RUN blocks at jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu (lines ~166–174, 183–198, 207–218, 297–306) with single-line RUN /bin/bash -Eeuxo pipefail -c '...' invocations and re-run hadolint in CI to confirm.
-FROM cpu-base AS common-builder -ARG TARGETARCH -USER root -RUN <<'EOF' -set -Eeuxo pipefail -if [ "${TARGETARCH}" = "ppc64le" ]; then - dnf install -y gcc-toolset-13 cmake ninja-build git wget unzip - dnf clean all -else - echo "Skipping common-builder package install on non-Power" -fi -EOF +FROM cpu-base AS common-builder +ARG TARGETARCH +USER root +RUN /bin/bash -Eeuxo pipefail -c 'if [ "${TARGETARCH}" = "ppc64le" ]; then dnf install -y gcc-toolset-13 cmake ninja-build git wget unzip && dnf clean all; else echo "Skipping common-builder package install on non-Power"; fi'-FROM common-builder AS onnx-builder -ARG TARGETARCH -ARG ONNX_VERSION=v1.19.0 -WORKDIR /root -RUN <<'EOF' -set -Eeuxo pipefail -if [ "${TARGETARCH}" = "ppc64le" ]; then - source /opt/rh/gcc-toolset-13/enable - git clone --recursive https://github.com/onnx/onnx.git - cd onnx - git checkout ${ONNX_VERSION} - git submodule update --init --recursive - pip install -r requirements.txt - export CMAKE_ARGS="-DPython3_EXECUTABLE=$(which python3.12)" - pip wheel . -w /root/onnx_wheel -else - echo "Skipping ONNX build on non-Power" - mkdir -p /root/onnx_wheel -fi -EOF +FROM common-builder AS onnx-builder +ARG TARGETARCH +ARG ONNX_VERSION=v1.19.0 +WORKDIR /root +RUN /bin/bash -Eeuxo pipefail -c 'if [ "${TARGETARCH}" = "ppc64le" ]; then source /opt/rh/gcc-toolset-13/enable && git clone --recursive https://github.com/onnx/onnx.git && cd onnx && git checkout ${ONNX_VERSION} && git submodule update --init --recursive && pip install -r requirements.txt && export CMAKE_ARGS="-DPython3_EXECUTABLE=$(which python3.12)" && pip wheel . -w /root/onnx_wheel; else echo "Skipping ONNX build on non-Power"; mkdir -p /root/onnx_wheel; fi'-FROM common-builder AS openblas-builder -ARG TARGETARCH -ARG OPENBLAS_VERSION=0.3.30 -WORKDIR /root -RUN <<'EOF' -set -Eeuxo pipefail -if [ "${TARGETARCH}" = "ppc64le" ]; then - 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 - mkdir -p OpenBLAS-${OPENBLAS_VERSION} - echo "Skipping OpenBLAS build on non-Power" -fi -EOF +FROM common-builder AS openblas-builder +ARG TARGETARCH +ARG OPENBLAS_VERSION=0.3.30 +WORKDIR /root +RUN /bin/bash -Eeuxo pipefail -c 'if [ "${TARGETARCH}" = "ppc64le" ]; then 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 DYNAMIC_ARCH=1 INTERFACE64=0; else mkdir -p OpenBLAS-${OPENBLAS_VERSION} && echo "Skipping OpenBLAS build on non-Power"; fi'-# Power-specific ONNX/OpenBLAS installation -RUN <<'EOF' -set -Eeuxo pipefail -if [ "${TARGETARCH}" = "ppc64le" ]; then - pip install /onnxwheels/*.whl - PREFIX=/usr/local make -C /openblas install - rm -rf /onnxwheels /openblas -else - echo "Skipping ONNX/OpenBLAS install on non-Power" -fi -EOF +# Power-specific ONNX/OpenBLAS installation +RUN /bin/bash -Eeuxo pipefail -c 'if [ "${TARGETARCH}" = "ppc64le" ]; then pip install /onnxwheels/*.whl && PREFIX=/usr/local make -C /openblas install && rm -rf /onnxwheels /openblas; else echo "Skipping ONNX/OpenBLAS install on non-Power"; fi'
|
/kfbuild odh-workbench-jupyter-datascience-cpu-py312-ubi9 so github actions ppc64le build just plain out timeouted |
|
and here's the ppc64le build error |
jiridanek
force-pushed
the
datascience-jupyter-multiarch
branch
from
d76226b to
a4e1b1e
Compare
There was a problem hiding this comment.
Actionable comments posted: 11
🧹 Nitpick comments (2)
jupyter/datascience/ubi9-python-3.12/pylock.toml (2)
565-565: colorful is pure-Python; ppc64le exclusion likely unnecessary.Unless there is a known runtime issue, keep it enabled on ppc64le. Apply markers in pyproject and re-lock; revert the added ppc64le clause.
-marker = "platform_machine != 'ppc64le' and platform_machine != 's390x'" +marker = "platform_machine != 's390x'"
2492-2543: OpenCensus/OpenTelemetry packages are pure-Python; blanket ppc64le exclusion removes useful telemetry.Unless a specific subpackage breaks on ppc64le, revert new ppc64le gating. Apply selective gating only where native deps (e.g., grpc exporter) are pulled.
-marker = "platform_machine != 'ppc64le' and platform_machine != 's390x'" +marker = "platform_machine != 's390x'"Also ensure grpc-based exporters are themselves gated on ppc64le in pyproject.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
.tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-pull-request.yaml(1 hunks)ci/cached-builds/gen_gha_matrix_jobs.py(4 hunks)jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu(4 hunks)jupyter/datascience/ubi9-python-3.12/pylock.toml(19 hunks)jupyter/datascience/ubi9-python-3.12/pyproject.toml(1 hunks)scripts/generate_pull_request_pipelineruns.py(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (5)
- jupyter/datascience/ubi9-python-3.12/pyproject.toml
- .tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-pull-request.yaml
- scripts/generate_pull_request_pipelineruns.py
- jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
- ci/cached-builds/gen_gha_matrix_jobs.py
🧰 Additional context used
🧠 Learnings (11)
📓 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#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T11:27:31.040Z
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#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T12:10:50.856Z
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.
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.856Z
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#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#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:232-249
Timestamp: 2025-09-12T08:27:00.439Z
Learning: jiridanek requested GitHub issue creation for Rust toolchain availability during s390x builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2432 review. Issue #2435 was created addressing PATH availability problems where Rust/cargo installed in cpu-base stage at /opt/.cargo/bin may not be accessible during uv pip install step in jupyter-datascience stage, proposing three solution approaches: immediate environment variable fix, builder stage pattern following codeserver approach, and ENV declaration fix, with comprehensive acceptance criteria covering build reliability, multi-architecture compatibility, and alignment with established patterns, continuing the systematic infrastructure improvement tracking methodology.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2317
File: codeserver/ubi9-python-3.12/get_code_server_rpm.sh:31-37
Timestamp: 2025-09-05T13:16:48.754Z
Learning: jiridanek requested GitHub issue creation for build tools installation unification across builder images during PR #2317 review. Issue #2322 was created addressing inconsistent build dependency management patterns across different builder images, proposing multiple solution approaches including Development Tools group installation, centralized configuration, and layered approaches, with comprehensive acceptance criteria covering auditing, standardization, regression prevention, and multi-architecture support (x86_64, ppc64le, aarch64, s390x), continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:232-249
Timestamp: 2025-09-12T08:27:00.439Z
Learning: jiridanek requested GitHub issue creation for Rust toolchain availability during s390x builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2432 review. The issue addresses PATH availability problems where Rust/cargo installed in cpu-base stage at /opt/.cargo/bin may not be accessible during uv pip install step in jupyter-datascience stage, proposing three solution approaches: immediate environment variable fix, builder stage pattern following codeserver approach, and ENV declaration fix, with comprehensive acceptance criteria covering build reliability, multi-architecture compatibility, and alignment with established patterns, continuing the systematic infrastructure improvement tracking methodology.
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.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2227
File: codeserver/ubi9-python-3.12/Dockerfile.cpu:122-123
Timestamp: 2025-09-05T12:25:09.719Z
Learning: jiridanek requested GitHub issue creation for Docker multi-stage synchronization improvement in codeserver/ubi9-python-3.12/Dockerfile.cpu during PR #2227 review. The issue addresses sentinel file pattern using /tmp/control copied to /dev/null for stage coordination between rpm-base, whl-cache, and codeserver stages, proposing semantic improvements with descriptive file names, inline documentation, and elimination of /dev/null hack while maintaining multi-architecture build functionality for ppc64le support.
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#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#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.
📚 Learning: 2025-09-05T10:05:35.575Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1513
File: runtimes/datascience/ubi9-python-3.12/pylock.toml:180-180
Timestamp: 2025-09-05T10:05:35.575Z
Learning: In Python lock files for the datascience runtime, both bcrypt and paramiko packages are excluded from s390x platform using the marker "platform_machine != 's390x'" due to compatibility issues on IBM System z mainframe architecture.
Applied to files:
jupyter/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:
jupyter/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:
jupyter/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-08-27T14:49:24.112Z
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.
Applied to files:
jupyter/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-09-12T23:07:03.779Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1875
File: jupyter/datascience/ubi9-python-3.12/pylock.toml:0-0
Timestamp: 2025-09-12T23:07:03.779Z
Learning: During PR #1875 review, jiridanek identified boto3/botocore/s3transfer dependency triplet misalignment across ubi9-python-3.12 images and requested GitHub issue creation. Issue #2447 was created to track systematic alignment of mixed versions (boto3: 1.37.38 vs 1.40.20, botocore: 1.37.38 vs 1.40.20, s3transfer: 0.11.5 vs 0.13.1) with target alignment to boto3==1.40.20, botocore==1.40.20, s3transfer==0.13.1 across all ubi9-python-3.12 pylock.toml files.
Applied to files:
jupyter/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-09-05T12:35:44.985Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2227
File: codeserver/ubi9-python-3.12/get_code_server_rpm.sh:18-19
Timestamp: 2025-09-05T12:35:44.985Z
Learning: jiridanek requested GitHub issue creation for architecture validation guard in codeserver/ubi9-python-3.12/get_code_server_rpm.sh during PR #2227 review. Issue #2320 was successfully created addressing missing validation for unknown architectures in UNAME_TO_GOARCH mapping lookup where empty ARCH values could cause silent failures, with comprehensive problem description, detailed proposed solution with code example, specific acceptance criteria, implementation considerations, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-08-29T15:18:43.229Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2215
File: runtimes/datascience/ubi9-python-3.12/pylock.toml:110-110
Timestamp: 2025-08-29T15:18:43.229Z
Learning: The file `runtimes/datascience/ubi9-python-3.12/pylock.toml` is a generated file and should not be edited directly. Changes should be made to the source pyproject.toml file instead.
Applied to files:
jupyter/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-07-21T15:06:04.114Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1396
File: runtimes/tensorflow/ubi9-python-3.12/Dockerfile.cuda:124-127
Timestamp: 2025-07-21T15:06:04.114Z
Learning: jiridanek requested GitHub issue creation for multi-platform dependency locking investigation during PR #1396 review. Issue #1423 was successfully created with comprehensive problem description covering ARM64 wheel availability but being ignored due to AMD64-only dependency locking, root cause analysis of platform-specific pipenv limitations, immediate conditional installation solution, multi-platform locking ecosystem analysis, broader affected areas investigation, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/datascience/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-09-05T11:27:31.040Z
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.040Z
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.
Applied to files:
jupyter/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:
jupyter/datascience/ubi9-python-3.12/pylock.toml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: build (jupyter-datascience-ubi9-python-3.12, 3.12, linux/ppc64le, false) / build
- GitHub Check: build (jupyter-datascience-ubi9-python-3.12, 3.12, linux/amd64, false) / build
🔇 Additional comments (6)
jupyter/datascience/ubi9-python-3.12/pylock.toml (6)
2958-2958: Exclude py-spy on ppc64le — gate parent dev-tooling in pyproject and re-lockNo 'py-spy' entry found in pyproject.toml. If py-spy is transitive via a dev-tooling dependency, add an architecture gate for ppc64le on that parent dependency in pyproject.toml (or the dev-tooling manifest), regenerate jupyter/datascience/ubi9-python-3.12/pylock.toml, and commit the updated lockfile.
4648-4648: Gate parent dependency on ppc64le (wrapt is transitive); do not edit pylock.Wrapt is not listed in pyproject.toml (it's transitive) and is a compiled extension. If no ppc64le wheels exist, keep the exclusion; otherwise allow. Gate the parent dependency in pyproject.toml and re-lock (do not modify pylock.toml directly).
108-108: Do not hand-edit pylock; move arch gating to pyproject and re-lock.pylock.toml files are autogenerated by uv — add any platform markers to the corresponding pyproject.toml and regenerate locks with:
uv lock --refresh
(verification environment lacked uv: "uv: command not found" — run locally or in CI to refresh and commit the regenerated pylock.)Affected: jupyter/datascience/ubi9-python-3.12/pylock.toml (aiohttp-cors at ~line 108); aiohttp-cors appears in multiple generated pylock files under runtimes/ and jupyter/. If exclusion is required, prefer gating only s390x (drop ppc64le) unless you have a confirmed ppc64le issue.
2048-2048: msgpack is transitive — gate the parent dependency, not msgpack directly.msgpack is not listed in pyproject.toml (transitive); apply the ppc64le exclusion to the top-level package that pulls in msgpack, update pyproject and re-lock. If you prefer to allow it instead, verify PyPI wheels exist for the exact locked msgpack version before relaxing the gate.
Likely an incorrect or invalid review comment.
552-552: ```shell
#!/bin/bash
set -euo pipefail
echo "PWD: $(pwd)"
echo "---- search for 'codeflare' / 'codeflare-sdk' ----"
rg -n --hidden --no-ignore-vcs "codeflare-sdk|codeflare" || true
echo "---- search for platform markers (platform_machine, ppc64le, marker) ----"
rg -n --hidden --no-ignore-vcs "platform_machine|ppc64le|marker|markers" || true
echo "---- list pyproject.toml files ----"
find . -type f -name pyproject.toml -print || true
for f in $(find . -type f -name pyproject.toml); do
echo "---- $f (first 200 lines) ----"
nl -ba "$f" | sed -n '1,200p'
done
PYLOCK="jupyter/datascience/ubi9-python-3.12/pylock.toml"
if [ -f "$PYLOCK" ]; then
echo "---- $PYLOCK lines 540-565 ----"
nl -ba "$PYLOCK" | sed -n '540,565p'
else
echo "---- $PYLOCK not found; listing jupyter/datascience ----"
ls -la jupyter/datascience || true
fi--- `225-225`: **Do not edit pylock — gate the parent dependency in pyproject.toml and regenerate the lock.** bcrypt is transitive (not listed in pyproject.toml). Move the platform marker to the direct dependency that pulls in bcrypt (or add bcrypt as a direct dependency with the marker if that was intended), then regenerate the lock files; do not modify pylock.toml by hand. Location: jupyter/datascience/ubi9-python-3.12/pylock.toml (bcrypt entry). </blockquote></details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
| name = "distlib" | ||
| version = "0.4.0" | ||
| marker = "platform_machine != 's390x'" | ||
| marker = "platform_machine != 'ppc64le' and platform_machine != 's390x'" |
There was a problem hiding this comment.
🛠️ Refactor suggestion
distlib is pure-Python; avoid over-gating.
Same rationale: revert ppc64le exclusion; move any gating to pyproject and re-lock.
-marker = "platform_machine != 'ppc64le' and platform_machine != 's390x'"
+marker = "platform_machine != 's390x'"📝 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' and platform_machine != 's390x'" | |
| marker = "platform_machine != 's390x'" |
🤖 Prompt for AI Agents
In jupyter/datascience/ubi9-python-3.12/pylock.toml around line 757, a platform
exclusion was applied to distlib even though it is pure-Python; remove the
ppc64le exclusion entry from the lockfile, move any platform gating (if still
desired) into pyproject.toml using environment markers (e.g. markers in the
dependency spec), and then re-lock/regenerate the lockfile so the change is
reflected consistently. Ensure the final pylock has no platform-specific
exclusion for distlib and that any conditional dependency rules live in
pyproject.toml before committing.
| name = "filelock" | ||
| version = "3.19.1" | ||
| marker = "platform_machine != 's390x'" | ||
| marker = "platform_machine != 'ppc64le' and platform_machine != 's390x'" |
There was a problem hiding this comment.
🛠️ Refactor suggestion
filelock is pure-Python; don’t exclude on ppc64le without reason.
Revert the added arch clause; apply markers only in pyproject and regenerate.
-marker = "platform_machine != 'ppc64le' and platform_machine != 's390x'"
+marker = "platform_machine != 's390x'"🤖 Prompt for AI Agents
In jupyter/datascience/ubi9-python-3.12/pylock.toml around line 812, the
filelock package was incorrectly marked as excluded for ppc64le; remove the
architecture-specific exclusion clause from the lockfile entry so filelock
remains available on ppc64le, then add any necessary platform markers only in
pyproject.toml (not in the lockfile), and regenerate the lockfile (e.g., run the
project's lock/update command) so the lockfile reflects the pyproject markers
correctly.
| name = "grpcio" | ||
| version = "1.74.0" | ||
| marker = "python_full_version >= '3.10' and platform_machine != 's390x'" | ||
| marker = "python_full_version >= '3.10' and platform_machine != 'ppc64le' and platform_machine != 's390x'" |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
grpcio gating: correct direction, but enforce at source and ensure dependents are gated too.
Exclude via pyproject (or by gating the parent deps that require grpcio, e.g., grpc exporters). Then re-lock; don’t edit pylock manually.
Ensure no un-gated packages still require grpcio on ppc64le.
🏁 Script executed:
#!/bin/bash
rg -n "grpcio|opentelemetry.*grpc" -g '!**/site-packages/**'Length of output: 148
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "PWD: $(pwd)"
echo "Top-level:"
ls -la | sed -n '1,200p'
if command -v rg >/dev/null 2>&1; then
echo "Using rg to search (includes hidden & ignored files)..."
rg -n --hidden --no-ignore -S "grpcio|opentelemetry.*grpc|opentelemetry.*exporter.*grpc" || true
echo "Searching for standalone 'grpc' token..."
rg -n --hidden --no-ignore -S '\bgrpc\b' || true
echo "Listing lock/pyproject files of interest:"
rg -n --hidden --no-ignore -S --files | rg -n "pylock.toml|pyproject.toml|poetry.lock|requirements" -n || true
else
echo "rg not found — falling back to find+grep..."
find . -type f -print0 | xargs -0 grep -nE "grpcio|opentelemetry.*grpc|opentelemetry.*exporter.*grpc" || true
fi
TARGET="jupyter/datascience/ubi9-python-3.12/pylock.toml"
if [ -f "$TARGET" ]; then
echo "---- Showing $TARGET lines 1160-1240 ----"
sed -n '1160,1240p' "$TARGET" | nl -ba -v1160 -w6 -s' '
echo "---- Searching for grpc mentions inside $TARGET ----"
if command -v rg >/dev/null 2>&1; then
rg -n "grpcio|grpc|opentelemetry" "$TARGET" || true
else
grep -nE "grpcio|grpc|opentelemetry" "$TARGET" || true
fi
else
echo "$TARGET not found — searching for any pylock.toml in repo..."
if command -v rg >/dev/null 2>&1; then
rg -n --hidden --no-ignore -S "pylock.toml" || true
else
find . -type f -name "pylock.toml" -print || true
fi
fiLength of output: 260072
Gate grpcio in pyproject (or gate the parent deps) and regenerate locks — do NOT edit pylock.toml manually.
Multiple runtime/jupyter lockfiles still contain grpcio; enforce the exclusion at the source (pyproject) or by gating parent deps such as OpenTelemetry gRPC exporters, then re-lock all affected images and verify ppc64le has no grpcio entries.
Affected lockfiles (examples):
- jupyter/datascience/ubi9-python-3.12/pylock.toml
- runtimes/datascience/ubi9-python-3.12/pylock.toml
- runtimes/tensorflow/ubi9-python-3.12/pylock.toml
- runtimes/pytorch/ubi9-python-3.12/pylock.toml
- jupyter/tensorflow/ubi9-python-3.12/pylock.toml
- jupyter/pytorch/ubi9-python-3.12/pylock.toml
- jupyter/trustyai/ubi9-python-3.12/pylock.toml
Re-run lock generation for all targets and confirm (e.g. rg -n --hidden --no-ignore -S 'grpcio') that no un-gated packages remain on ppc64le.
| name = "invoke" | ||
| version = "2.2.0" | ||
| marker = "platform_machine != 's390x'" | ||
| marker = "platform_machine != 'ppc64le' and platform_machine != 's390x'" |
There was a problem hiding this comment.
🛠️ Refactor suggestion
invoke is pure-Python; revert ppc64le exclusion unless there’s a documented issue.
Move any markers to pyproject and re-lock.
-marker = "platform_machine != 'ppc64le' and platform_machine != 's390x'"
+marker = "platform_machine != 's390x'"📝 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' and platform_machine != 's390x'" | |
| marker = "platform_machine != 's390x'" |
🤖 Prompt for AI Agents
In jupyter/datascience/ubi9-python-3.12/pylock.toml around line 1348 there is an
exclusion marker for ppc64le for the invoke package; remove that exclusion since
invoke is pure-Python, move any platform-specific markers into pyproject.toml
(e.g., use appropriate optional-dependencies or environment markers) and then
re-run the lock process to regenerate pylock.toml so the dependency is correctly
included for ppc64le.
| name = "markdown-it-py" | ||
| version = "4.0.0" | ||
| marker = "platform_machine != 's390x'" | ||
| marker = "platform_machine != 'ppc64le' and platform_machine != 's390x'" |
There was a problem hiding this comment.
🛠️ Refactor suggestion
markdown-it-py is pure-Python; avoid excluding on ppc64le.
Same action: revert ppc64le clause; set markers in pyproject; uv lock.
-marker = "platform_machine != 'ppc64le' and platform_machine != 's390x'"
+marker = "platform_machine != 's390x'"Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In jupyter/datascience/ubi9-python-3.12/pylock.toml around line 1708, remove the
ppc64le exclusion for markdown-it-py (it is pure-Python and should not be
excluded), revert the ppc64le clause, ensure any platform-specific constraints
are expressed as environment markers in pyproject.toml (so pure-Python packages
remain unexcluded), then regenerate the lockfile (run the project’s lock
command, e.g., uv lock) to update pylock.toml accordingly.
| name = "paramiko" | ||
| version = "4.0.0" | ||
| marker = "platform_machine != 's390x'" | ||
| marker = "platform_machine != 'ppc64le' and platform_machine != 's390x'" |
There was a problem hiding this comment.
🛠️ Refactor suggestion
paramiko depends on bcrypt; gating both is consistent—do it upstream and re-lock.
Keep exclusion if bcrypt remains excluded; move markers to pyproject and regenerate the lock.
🤖 Prompt for AI Agents
In jupyter/datascience/ubi9-python-3.12/pylock.toml around line 2620, paramiko
is indirectly dependent on bcrypt but the current locking/exclusion markers are
inconsistent; move the exclusion marker(s) from the lockfile into pyproject.toml
so gating is applied upstream (add the bcrypt exclusion and any related marker
for paramiko in pyproject), then regenerate the lockfile (re-lock) so both
packages are treated consistently; if you choose to keep bcrypt excluded, ensure
the exclusion remains in pyproject and re-run the lock generation to produce a
consistent pylock.toml.
| name = "ray" | ||
| version = "2.47.1" | ||
| marker = "platform_machine != 's390x'" | ||
| marker = "platform_machine != 'ppc64le' and platform_machine != 's390x'" |
There was a problem hiding this comment.
🛠️ Refactor suggestion
ray: correct to exclude on ppc64le; commit marker in pyproject and re-lock.
🤖 Prompt for AI Agents
jupyter/datascience/ubi9-python-3.12/pylock.toml around line 3562: the lockfile
currently includes ray for the ppc64le platform and lacks the matching commit
marker in pyproject; update pyproject.toml to include the commit marker for ray
(same commit hash used in the lock), modify the lock constraints so ray is
excluded for the ppc64le/ppc64el platform (remove/add platform-specific markers
in pylock.toml accordingly), then re-run your dependency lock command
(poetry/pip-tools as used in this repo) to regenerate pylock.toml so the
exclusion and commit marker are consistent.
| name = "rich" | ||
| version = "13.9.4" | ||
| marker = "platform_machine != 's390x'" | ||
| marker = "platform_machine != 'ppc64le' and platform_machine != 's390x'" |
There was a problem hiding this comment.
🛠️ Refactor suggestion
rich is pure-Python; excluding on ppc64le is unnecessary.
Revert ppc64le clause; keep s390x rule if previously required; move markers to pyproject and re-lock.
-marker = "platform_machine != 'ppc64le' and platform_machine != 's390x'"
+marker = "platform_machine != 's390x'"📝 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' and platform_machine != 's390x'" | |
| marker = "platform_machine != 's390x'" |
🤖 Prompt for AI Agents
In jupyter/datascience/ubi9-python-3.12/pylock.toml around line 3641, the
lockfile currently excludes rich for ppc64le which is unnecessary because rich
is pure-Python; remove the ppc64le exclusion clause from the pylock.toml, keep
the s390x exclusion only if it was previously required, and instead add any
platform markers to pyproject.toml dependency entries (so package resolution is
correct across platforms), then regenerate/lock dependencies (poetry/pip-tools)
to produce an updated pylock.toml without the ppc64le exclusion.
| name = "smart-open" | ||
| version = "7.3.1" | ||
| marker = "platform_machine != 's390x'" | ||
| marker = "platform_machine != 'ppc64le' and platform_machine != 's390x'" |
There was a problem hiding this comment.
🛠️ Refactor suggestion
smart-open is pure-Python; avoid blanket ppc64le exclusion.
-marker = "platform_machine != 'ppc64le' and platform_machine != 's390x'"
+marker = "platform_machine != 's390x'"📝 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' and platform_machine != 's390x'" | |
| marker = "platform_machine != 's390x'" |
🤖 Prompt for AI Agents
In jupyter/datascience/ubi9-python-3.12/pylock.toml at line 4004, the lockfile
currently excludes smart-open for ppc64le; since smart-open is pure-Python,
remove or adjust that blanket ppc64le exclusion so the package is not filtered
out for that architecture—edit the exclusion entry to either delete smart-open
from the ppc64le exclusion list or mark it as platform-independent/compatible so
the lockfile includes smart-open for ppc64le.
| name = "virtualenv" | ||
| version = "20.34.0" | ||
| marker = "platform_machine != 's390x'" | ||
| marker = "platform_machine != 'ppc64le' and platform_machine != 's390x'" |
There was a problem hiding this comment.
🛠️ Refactor suggestion
virtualenv is pure-Python; don’t exclude on ppc64le.
-marker = "platform_machine != 'ppc64le' and platform_machine != 's390x'"
+marker = "platform_machine != 's390x'"📝 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' and platform_machine != 's390x'" | |
| marker = "platform_machine != 's390x'" |
🤖 Prompt for AI Agents
In jupyter/datascience/ubi9-python-3.12/pylock.toml at line 4376, there's an
exclusion entry that prevents virtualenv from being included on ppc64le;
virtualenv is pure-Python so this platform exclusion is incorrect. Remove
ppc64le from the exclusion list for the virtualenv entry (or mark the package as
pure-Python/purelib so it’s not platform-restricted) so virtualenv is available
on ppc64le builds.
There was a problem hiding this comment.
pylock.tomls are autgenerated from pyproject.txts, this is just how the uv dependency resolution turned out
anything wrong with it? should we use --universal?
There was a problem hiding this comment.
, but this specific case with virtualenv suggests that the current approach might be overly restrictive for pure Python packages.
I'd recommend testing --universal in your build process to see if it resolves the virtualenv exclusion while maintaining compatibility with your multi-architecture builds. This would be a more systematic solution than trying to patch individual package markers.
✏️ Learnings added
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2460
File: jupyter/datascience/ubi9-python-3.12/pylock.toml:4376-4376
Timestamp: 2025-09-15T18:14:37.600Z
Learning: jiridanek confirmed that pylock.toml files are autogenerated from pyproject.toml files using uv dependency resolution, and asked about using --universal flag to address platform exclusion issues with pure Python packages like virtualenv.
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: jiridanek
PR: opendatahub-io/notebooks#1513
File: runtimes/datascience/ubi9-python-3.12/pylock.toml:180-180
Timestamp: 2025-09-05T10:05:35.575Z
Learning: In Python lock files for the datascience runtime, both bcrypt and paramiko packages are excluded from s390x platform using the marker "platform_machine != 's390x'" due to compatibility issues on IBM System z mainframe architecture.
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.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/pylock.toml:534-536
Timestamp: 2025-09-12T08:39:17.540Z
Learning: In the opendatahub-io/notebooks project, not all container images are s390x enabled yet. Images without platform markers (like `marker = "platform_machine != 's390x'"`) simply haven't been patched for s390x support yet, indicating a phased rollout approach for s390x enablement across different notebook images.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2215
File: runtimes/datascience/ubi9-python-3.12/pylock.toml:110-110
Timestamp: 2025-08-29T15:18:43.229Z
Learning: When uv compiles dependencies with platform restrictions (like `platform_machine != 'ppc64le'`), it automatically propagates these markers to transitive dependencies in the generated lock files. This is expected behavior and doesn't require manual intervention in source files.
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.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2233
File: tests/test_main.py:46-56
Timestamp: 2025-09-02T07:55:31.824Z
Learning: jiridanek deferred a suggestion for enhanced pyproject.toml/pylock.toml validation in PR #2233 tests/test_main.py. The current test implementation works fine, but future enhancements may need: name normalization using canonicalize_name() to handle case/separator mismatches, environment markers evaluation to skip dependencies not applicable to the image's Python/OS, and handling non-PEP440 versions from VCS/URL dependencies by checking if locked_version exists before asserting specifier.contains(). The deferred implementation includes evaluating markers against image environment (_env = {"python_version": python, "sys_platform": "linux", "platform_system": "Linux"}) and using tomllib.load() with binary mode for consistency.
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.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1396
File: runtimes/tensorflow/ubi9-python-3.12/Dockerfile.cuda:124-127
Timestamp: 2025-07-21T15:06:04.114Z
Learning: jiridanek requested GitHub issue creation for multi-platform dependency locking investigation during PR #1396 review. Issue #1423 was successfully created with comprehensive problem description covering ARM64 wheel availability but being ignored due to AMD64-only dependency locking, root cause analysis of platform-specific pipenv limitations, immediate conditional installation solution, multi-platform locking ecosystem analysis, broader affected areas investigation, 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#2215
File: runtimes/datascience/ubi9-python-3.12/pylock.toml:110-110
Timestamp: 2025-08-29T15:18:43.229Z
Learning: The file `runtimes/datascience/ubi9-python-3.12/pylock.toml` is a generated file and should not be edited directly. Changes should be made to the source pyproject.toml file instead.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:232-249
Timestamp: 2025-09-12T08:27:00.439Z
Learning: jiridanek requested GitHub issue creation for Rust toolchain availability during s390x builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2432 review. The issue addresses PATH availability problems where Rust/cargo installed in cpu-base stage at /opt/.cargo/bin may not be accessible during uv pip install step in jupyter-datascience stage, proposing three solution approaches: immediate environment variable fix, builder stage pattern following codeserver approach, and ENV declaration fix, with comprehensive acceptance criteria covering build reliability, multi-architecture compatibility, and alignment with established patterns, continuing the systematic infrastructure improvement tracking methodology.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/pylock.toml:105-111
Timestamp: 2025-09-12T08:38:43.732Z
Learning: The pylock.toml file in jupyter/datascience/ubi9-python-3.12/ is autogenerated by uv and should not be manually edited. Changes should be made to the source files like pyproject.toml instead.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-30T07:57:33.466Z
Learning: uv's official documentation recommends against using both uv.lock and requirements.txt (or exported formats like pylock.toml) simultaneously. The recommended approach is to use either uv.lock for uv-native workflows OR exported formats for compatibility, but not both. If both are needed, uv suggests opening an issue to discuss the specific use case.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2215
File: runtimes/datascience/ubi9-python-3.12/pylock.toml:10-10
Timestamp: 2025-08-29T15:17:41.893Z
Learning: Files named pylock.toml in the notebooks repository are autogenerated by uv from pyproject.toml files and should not be directly modified. Changes should be made to the source pyproject.toml file instead.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2215
File: runtimes/datascience/ubi9-python-3.12/pylock.toml:110-110
Timestamp: 2025-08-29T15:18:43.229Z
Learning: Files with names like `pylock.toml` that contain generation headers (showing commands like `uv pip compile`) are auto-generated and should not be edited directly. Changes should be made to the source files they're compiled from.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: Makefile:451-457
Timestamp: 2025-08-27T16:04:49.874Z
Learning: jiridanek requested GitHub issue creation for uv command optimization during PR #2145 review, specifically to explore using `uv export -o pylock.toml` instead of `uv pip compile pyproject.toml` for lockfile generation. Issue addresses the technical question of which uv command is more appropriate given the current workflow that uses both `uv lock` and pylock.toml generation. The investigation will cover technical differences, workflow integration, performance comparison, and alignment with uv best practices to determine the optimal approach for the project's lockfile generation pipeline.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: Makefile:451-457
Timestamp: 2025-08-27T16:04:49.874Z
Learning: jiridanek requested GitHub issue creation for uv command optimization during PR #2145 review, specifically to explore using `uv export -o pylock.toml` instead of `uv pip compile pyproject.toml` for lockfile generation. Issue #2163 was created addressing the technical question of which uv command is more appropriate given the current workflow that uses both `uv lock` and pylock.toml generation. The investigation covers technical differences, workflow integration, performance comparison, and alignment with uv best practices to determine the optimal approach for the project's lockfile generation pipeline across 18+ notebook/runtime environments.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-31T16:15:13.993Z
Learning: jiridanek confirmed closure of GitHub issue #574 regarding Python version-specific Pipfile.lock generation, which was resolved automatically by the uv migration in PR #2145. The uv tool inherently handles Python version context during lock file generation, eliminating the need for manual version specification that was required with pipenv.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-31T16:15:13.993Z
Learning: jiridanek confirmed closure of GitHub issue #574 regarding Python version-specific Pipfile.lock generation, which was resolved automatically by the uv migration in PR #2145. The uv tool inherently handles Python version context during lock file generation, eliminating the need for manual version specification that was required with pipenv.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2113
File: pyproject.toml:0-0
Timestamp: 2025-08-26T16:29:14.781Z
Learning: In opendatahub-io/notebooks, jiridanek's team uses selective dependency group resolution via scripts/sync-requirements-txt.sh instead of universal `uv lock --universal` resolution. This approach resolves individual image dependency groups (like jupyter-tensorflow-image) separately, making conflict matrices in pyproject.toml unnecessary since conflicting combinations between different image types never occur in the same resolution context.
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#2227
File: codeserver/ubi9-python-3.12/get_code_server_rpm.sh:18-19
Timestamp: 2025-09-05T12:35:44.985Z
Learning: jiridanek requested GitHub issue creation for architecture validation guard in codeserver/ubi9-python-3.12/get_code_server_rpm.sh during PR #2227 review. Issue #2320 was successfully created addressing missing validation for unknown architectures in UNAME_TO_GOARCH mapping lookup where empty ARCH values could cause silent failures, with comprehensive problem description, detailed proposed solution with code example, specific acceptance criteria, implementation considerations, 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#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T11:27:31.040Z
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#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T12:10:50.856Z
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.
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.856Z
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#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#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:232-249
Timestamp: 2025-09-12T08:27:00.439Z
Learning: jiridanek requested GitHub issue creation for Rust toolchain availability during s390x builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2432 review. Issue #2435 was created addressing PATH availability problems where Rust/cargo installed in cpu-base stage at /opt/.cargo/bin may not be accessible during uv pip install step in jupyter-datascience stage, proposing three solution approaches: immediate environment variable fix, builder stage pattern following codeserver approach, and ENV declaration fix, with comprehensive acceptance criteria covering build reliability, multi-architecture compatibility, and alignment with established patterns, continuing the systematic infrastructure improvement tracking methodology.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2317
File: codeserver/ubi9-python-3.12/get_code_server_rpm.sh:31-37
Timestamp: 2025-09-05T13:16:48.754Z
Learning: jiridanek requested GitHub issue creation for build tools installation unification across builder images during PR #2317 review. Issue #2322 was created addressing inconsistent build dependency management patterns across different builder images, proposing multiple solution approaches including Development Tools group installation, centralized configuration, and layered approaches, with comprehensive acceptance criteria covering auditing, standardization, regression prevention, and multi-architecture support (x86_64, ppc64le, aarch64, s390x), continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
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.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2227
File: codeserver/ubi9-python-3.12/Dockerfile.cpu:122-123
Timestamp: 2025-09-05T12:25:09.719Z
Learning: jiridanek requested GitHub issue creation for Docker multi-stage synchronization improvement in codeserver/ubi9-python-3.12/Dockerfile.cpu during PR #2227 review. The issue addresses sentinel file pattern using /tmp/control copied to /dev/null for stage coordination between rpm-base, whl-cache, and codeserver stages, proposing semantic improvements with descriptive file names, inline documentation, and elimination of /dev/null hack while maintaining multi-architecture build functionality for ppc64le support.
There was a problem hiding this comment.
u're talking nonsense, go back in your burrow
There was a problem hiding this comment.
@jiridanek I understand you're frustrated with my suggestion. You know your build process and uv dependency resolution much better than I do. I'll step back from making recommendations about the --universal flag since it's not helpful in your context.
(\ /)
( ._.)
o_(")(")
🧠 Learnings used
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1513
File: runtimes/datascience/ubi9-python-3.12/pylock.toml:180-180
Timestamp: 2025-09-05T10:05:35.575Z
Learning: In Python lock files for the datascience runtime, both bcrypt and paramiko packages are excluded from s390x platform using the marker "platform_machine != 's390x'" due to compatibility issues on IBM System z mainframe architecture.
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.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2460
File: jupyter/datascience/ubi9-python-3.12/pylock.toml:4376-4376
Timestamp: 2025-09-15T18:14:37.624Z
Learning: jiridanek confirmed that pylock.toml files are autogenerated from pyproject.toml files using uv dependency resolution, and asked about using --universal flag to address platform exclusion issues with pure Python packages like virtualenv.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/pylock.toml:534-536
Timestamp: 2025-09-12T08:39:17.540Z
Learning: In the opendatahub-io/notebooks project, not all container images are s390x enabled yet. Images without platform markers (like `marker = "platform_machine != 's390x'"`) simply haven't been patched for s390x support yet, indicating a phased rollout approach for s390x enablement across different notebook images.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2227
File: codeserver/ubi9-python-3.12/Dockerfile.cpu:122-123
Timestamp: 2025-09-05T12:25:09.719Z
Learning: jiridanek requested GitHub issue creation for Docker multi-stage synchronization improvement in codeserver/ubi9-python-3.12/Dockerfile.cpu during PR #2227 review. The issue addresses sentinel file pattern using /tmp/control copied to /dev/null for stage coordination between rpm-base, whl-cache, and codeserver stages, proposing semantic improvements with descriptive file names, inline documentation, and elimination of /dev/null hack while maintaining multi-architecture build functionality for ppc64le support.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:232-249
Timestamp: 2025-09-12T08:27:00.439Z
Learning: jiridanek requested GitHub issue creation for Rust toolchain availability during s390x builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2432 review. The issue addresses PATH availability problems where Rust/cargo installed in cpu-base stage at /opt/.cargo/bin may not be accessible during uv pip install step in jupyter-datascience stage, proposing three solution approaches: immediate environment variable fix, builder stage pattern following codeserver approach, and ENV declaration fix, with comprehensive acceptance criteria covering build reliability, multi-architecture compatibility, and alignment with established patterns, continuing the systematic infrastructure improvement tracking methodology.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2227
File: codeserver/ubi9-python-3.12/Dockerfile.cpu:126-128
Timestamp: 2025-09-05T12:25:58.344Z
Learning: jiridanek expressed concern about code-server installation complexity in codeserver/ubi9-python-3.12/Dockerfile.cpu during PR #2227 review, describing the multi-stage cache mount approach as a "hack" that worries them. GitHub issue #2315 was created addressing the architectural complexity with comprehensive problem description, four solution options, clear acceptance criteria, and implementation considerations, assigned to jiridanek, continuing the established pattern of systematic technical improvement 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.856Z
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.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:232-249
Timestamp: 2025-09-12T08:27:00.439Z
Learning: jiridanek requested GitHub issue creation for Rust toolchain availability during s390x builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2432 review. Issue #2435 was created addressing PATH availability problems where Rust/cargo installed in cpu-base stage at /opt/.cargo/bin may not be accessible during uv pip install step in jupyter-datascience stage, proposing three solution approaches: immediate environment variable fix, builder stage pattern following codeserver approach, and ENV declaration fix, with comprehensive acceptance criteria covering build reliability, multi-architecture compatibility, and alignment with established patterns, continuing the systematic infrastructure improvement tracking methodology.
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.856Z
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#2227
File: codeserver/ubi9-python-3.12/Dockerfile.cpu:126-128
Timestamp: 2025-09-05T12:25:58.344Z
Learning: jiridanek expressed concern about code-server installation complexity in codeserver/ubi9-python-3.12/Dockerfile.cpu during PR #2227 review, describing the multi-stage cache mount approach as a "hack" that worries them, leading to GitHub issue creation for systematic architectural improvement addressing maintainability concerns.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2227
File: codeserver/ubi9-python-3.12/Dockerfile.cpu:218-218
Timestamp: 2025-09-05T12:29:07.819Z
Learning: jiridanek requested GitHub issue creation for uv multi-stage Docker build architectural investigation during PR #2227 review. The current implementation uses a three-stage build with whl-cache stage for wheel building/caching, base stage for OS setup, and final codeserver stage for offline installation using --offline flag and cache mounts. The pattern separates build phase (internet access, build tools) from install phase (offline, faster) while supporting multi-architecture builds (x86_64, ppc64le) with sentinel file coordination using /tmp/control files.
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. Analysis confirmed duplication exists in both pytorch+llmcompressor Dockerfiles with micropipenv installed twice: unpinned early install (lines 23/36) for Pipfile.lock deployment and pinned later install (lines 160/248) in requirements.txt block. Issue #1999 created with comprehensive problem analysis covering exact line numbers and affected files, three solution options (remove early install, consolidate installations, conditional logic), detailed acceptance criteria covering build testing and functionality verification, implementation notes for coordination with version pinning efforts, and proper context linking to PR #1998 review comment.
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#2227
File: codeserver/ubi9-python-3.12/get_code_server_rpm.sh:18-19
Timestamp: 2025-09-05T12:35:44.985Z
Learning: jiridanek requested GitHub issue creation for architecture validation guard in codeserver/ubi9-python-3.12/get_code_server_rpm.sh during PR #2227 review. Issue #2320 was successfully created addressing missing validation for unknown architectures in UNAME_TO_GOARCH mapping lookup where empty ARCH values could cause silent failures, with comprehensive problem description, detailed proposed solution with code example, specific acceptance criteria, implementation considerations, 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#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T11:27:31.040Z
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#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#2317
File: codeserver/ubi9-python-3.12/get_code_server_rpm.sh:31-37
Timestamp: 2025-09-05T13:16:48.754Z
Learning: jiridanek requested GitHub issue creation for build tools installation unification across builder images during PR #2317 review. Issue #2322 was created addressing inconsistent build dependency management patterns across different builder images, proposing multiple solution approaches including Development Tools group installation, centralized configuration, and layered approaches, with comprehensive acceptance criteria covering auditing, standardization, regression prevention, and multi-architecture support (x86_64, ppc64le, aarch64, s390x), continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
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.
|
/kfbuild odh-workbench-jupyter-datascience-cpu-py312-ubi9 |
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (5)
codeserver/ubi9-python-3.12/Dockerfile.cpu (1)
89-97: OpenBLAS install path is broken; stage doesn’t provide /root/OpenBLAS.You mount from whl-cache and then run
make install -C /OpenBlas, butwhl-cachenever builds OpenBLAS, so/OpenBlasis empty/missing on ppc64le. This will either no‑op or fail at runtime. Build OpenBLAS in a dedicated builder stage and copy installed artifacts instead of compiling in cpu-base.Apply one of these diffs:
Option A (remove until a proper builder is added)
-# (ARCH-ppc64le): since wheels are compiled from source, we need shared libs available at runtime -RUN --mount=type=cache,from=whl-cache,source=/root/OpenBLAS,target=/OpenBlas,rw \ - bash -c ' \ - if [[ $(uname -m) == "ppc64le" ]]; then \ - dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm; \ - dnf install -y lcms2 libraqm libimagequant openjpeg2; \ - PREFIX=/usr/ make install -C /OpenBlas; \ - fi ' +## (ARCH-ppc64le) TODO: add OpenBLAS builder stage and copy /usr/local artifacts hereOption B (introduce local builder alias; mirror pattern from datascience Dockerfile)
+################################### +# openblas builder stage for ppc64le +################################### +FROM ${BASE_IMAGE} AS openblas-builder +USER 0 +WORKDIR /root +ENV OPENBLAS_VERSION=0.3.30 +RUN if [ "$(uname -m)" = "ppc64le" ]; then \ + dnf install -y git gcc-toolset-13 make wget unzip cmake && \ + 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 DYNAMIC_ARCH=1 USE_OPENMP=1 && \ + make PREFIX=/usr/local install; \ + fi @@ -FROM ${BASE_IMAGE} AS cpu-base +FROM ${BASE_IMAGE} AS cpu-base @@ -# (ARCH-ppc64le): since wheels are compiled from source, we need shared libs available at runtime -RUN --mount=type=cache,from=whl-cache,source=/root/OpenBLAS,target=/OpenBlas,rw \ - bash -c ' \ - if [[ $(uname -m) == "ppc64le" ]]; then \ - dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm; \ - dnf install -y lcms2 libraqm libimagequant openjpeg2; \ - PREFIX=/usr/ make install -C /OpenBlas; \ - fi ' +COPY --from=openblas-builder /usr/local /usr/localruntimes/datascience/ubi9-python-3.12/Dockerfile.cpu (2)
49-56: Don’t export build‑only vars to profile.d (tracked in Issue #2311).OPENBLAS_VERSION/ONNX_VERSION/GRPC_PYTHON_BUILD_SYSTEM_OPENSSL and PATH tweaks shouldn’t bleed into runtime shells; keep them as ARG/ENV within the relevant builder stages.
-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 +# ppc64le build env is scoped to builder stages; avoid leaking to runtime shellsFollow‑up: set
ENV OPENBLAS_VERSION=0.3.30in openblas-builder andENV ONNX_VERSION=1.19.0in onnx-builder (you already do for both).
226-235: Do not runmake installof OpenBLAS in the final image; copy installed files from builder.This pattern causes permission issues in some rootless build environments and lengthens builds. Install in openblas-builder, then copy
/usr/local(or/usr) into runtime.-COPY --from=openblas-builder /root/OpenBLAS-* /openblas +COPY --from=openblas-builder /usr/local /usr/local @@ -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; \ +RUN if [ "$TARGETARCH" = "ppc64le" ]; then \ + echo "Installing ppc64le ONNX wheels..." && \ + HOME=/root pip install --no-cache-dir /tmp/onnx_wheels/*.whl && \ + rm -rf /tmp/onnx_wheels; \ else \ echo "Skipping architecture-specific wheel installs for (${TARGETARCH})" && \ - rm -rf /tmp/wheels /openblas /tmp/onnx_wheels; \ + rm -rf /tmp/wheels /tmp/onnx_wheels; \ fijupyter/datascience/ubi9-python-3.12/Dockerfile.cpu (2)
115-160: s390x wheel-builder is missing git (will fail on git clone).The stage clones Arrow but doesn’t install git.
- dnf install -y cmake make gcc-c++ pybind11-devel wget && \ + dnf install -y cmake make gcc-c++ pybind11-devel wget git && \Optional: consider
ninja-buildto speed CMake builds if available.
1-1: Add top-line# syntax=header for Dockerfiles using heredocs. Detected heredoc in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu but the first line is missing a# syntax=directive; add e.g.# syntax=docker/dockerfile:1as line 1 to satisfy Hadolint/BuildKit.
🧹 Nitpick comments (26)
runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu (6)
21-21: Reference a named alias for COPY --from=ubi to satisfy DL3022.Minor hadolint fix; define an alias once and reuse.
-FROM ${BASE_IMAGE} AS cpu-base +FROM ${BASE_IMAGE} AS cpu-base +FROM registry.access.redhat.com/ubi9/ubi AS ubi9src @@ -COPY --from=registry.access.redhat.com/ubi9/ubi /etc/yum.repos.d/ubi.repo /etc/yum.repos.d/ubi.repo +COPY --from=ubi9src /etc/yum.repos.d/ubi.repo /etc/yum.repos.d/ubi.repo
33-47: Package gating by TARGETARCH reads well; minor consistency nit.You use
uname -min other files and${TARGETARCH}here; both are fine, but prefer${TARGETARCH}consistently within the file.
106-150: s390x pyarrow build: add --no-cache-dir and reduce bundle size.Minor cleanups for hadolint DL3042 and image bloat.
- pip install --no-cache-dir -r requirements-build.txt && \ + pip install --no-cache-dir -r requirements-build.txt && \ PYARROW_WITH_PARQUET=1 \ @@ - mkdir -p /tmp/wheels && \ - cp dist/pyarrow-*.whl /tmp/wheels/ && \ + mkdir -p /tmp/wheels && \ + cp dist/pyarrow-*.whl /tmp/wheels/ && \ # Ensure wheels directory exists and has content ls -la /tmp/wheels/; \(Keep
--no-cache-dir; also consider cleaning the Arrow source tree after copying the wheel.)
167-174: OpenBLAS builder: add progress flag and install in builder (not final).Small wget nit and future‑proofing: complete install here and copy the prefix later.
- wget https://github.com/OpenMathLib/OpenBLAS/releases/download/v${OPENBLAS_VERSION}/OpenBLAS-${OPENBLAS_VERSION}.zip && \ + wget --progress=dot:giga 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; \ + make -j"$(nproc)" TARGET=POWER9 BINARY=64 USE_OPENMP=1 USE_THREAD=1 NUM_THREADS=120 DYNAMIC_ARCH=1 INTERFACE64=0 && \ + make PREFIX=/usr/local install;
189-199: onnx-builder: add --no-cache-dir and keep builds hermetic.Avoid pip cache and pin Python explicitly via
CMAKE_ARGSas you already do.- pip install -r requirements.txt && \ + pip install --no-cache-dir -r requirements.txt && \ export CMAKE_ARGS="-DPython3_EXECUTABLE=$(which python3.12)" && \ pip wheel . -w /onnx_wheels; \
156-156: Optional: restore non‑root at end of builder stages to quiet DL3002.Not functionally required, but setting
USER 1001at the end of builder stages avoids lints. Up to you.Also applies to: 201-201
rstudio/rhel9-python-3.11/Dockerfile.cpu (1)
16-18: Guard against partial upgrades from--skip-brokenCombining
--bestwith--skip-brokencan yield partial upgrades and inconsistent images. At minimum, log remaining security updates (or gate--skip-brokenbehind a build ARG) so compliance scans aren’t surprised.Once you adjust the generator as suggested, re-run it rather than editing Dockerfiles by hand.
jupyter/rocm/tensorflow/ubi9-python-3.12/Dockerfile.rocm (1)
35-38: Visibility for skipped updatesSame
--skip-brokenconcern as elsewhere. Please rely on the fragment generator to also print outstanding security advisories after upgrade for auditability.jupyter/minimal/ubi9-python-3.12/Dockerfile.cuda (1)
24-27: Consistent upgrade behavior and logsApply the fragment change so this stage also surfaces any skipped security advisories caused by
--skip-broken.runtimes/rocm-pytorch/ubi9-python-3.12/Dockerfile.rocm (1)
22-25: Track what--skip-brokenleaves behindPlease adopt the fragment tweak to print remaining security advisories post-upgrade to keep runtime image hardening transparent.
rstudio/c9s-python-3.11/Dockerfile.cuda (1)
23-26: Partial-upgrade risk with--skip-brokenMirror the generator change here so CI logs clearly show any advisories left after the tolerant upgrade.
jupyter/tensorflow/ubi9-python-3.12/Dockerfile.cuda (1)
37-40: Surface skipped security updates in logsPlease rely on the updated fragment to emit
dnf updateinfo …after the--skip-brokenupgrade for traceability.jupyter/rocm/pytorch/ubi9-python-3.12/Dockerfile.rocm (1)
35-38: Make tolerant upgrades auditableSame note: adopt the fragment enhancement so we log remaining security advisories after using
--skip-broken.jupyter/minimal/ubi9-python-3.12/Dockerfile.rocm (1)
22-25: Adding --skip-broken is fine; please surface skipped packages.To avoid silently missing security updates, print what got skipped (e.g.,
dnf upgrade ... || true && dnf repoquery --unsatisfied && dnf updateinfo --security list updates). Low-friction logging helps troubleshooting later.rstudio/rhel9-python-3.11/Dockerfile.cuda (3)
18-21: --skip-broken addition: OK with a caveat.Good for resiliency; consider logging skipped packages as noted in other files to keep visibility on potentially unpatched CVEs.
26-26: Redundant cache removal.
dnf clean allis sufficient. Droprm -rf /var/cache/yumto avoid churn and keep to the project guidance.-RUN dnf install -y mesa-libGL && dnf clean all && rm -rf /var/cache/yum +RUN dnf install -y mesa-libGL && dnf clean all
175-176: Typo in label keys: io.k9s → io.k8s.These two labels won’t be recognized by tooling.
- io.k9s.display-name="RStudio Server image with python 3.11 based on Red Hat Enterprise Linux 9" \ - io.k9s.description="RStudio Server image with python 3.11 based on Red Hat Enterprise Linux 9" \ + io.k8s.display-name="RStudio Server image with python 3.11 based on Red Hat Enterprise Linux 9" \ + io.k8s.description="RStudio Server image with python 3.11 based on Red Hat Enterprise Linux 9" \runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm (1)
22-25: OK to tolerate conflicts; add visibility.Please echo skipped packages (or run
dnf updateinfo --security list updates) after the upgrade to ensure we don’t mask important security updates.runtimes/pytorch+llmcompressor/ubi9-python-3.12/Dockerfile.cuda (1)
24-27: Resilient upgrade: OK.Same note as elsewhere: log skipped packages to aid CVE triage.
jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda (1)
37-40: Resilient upgrade: OK.Consider consistent logging of skipped packages for auditability.
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu (6)
68-81: Avoid writing build-only env into profile.d.These shells aren’t login shells; profile scripts won’t reliably apply. You already pass GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1 inline during uv install below. Drop the profile writes to reduce drift.
- chown -R 1001:0 /opt/.cargo && \ - # Set environment variables - echo 'export PATH=/opt/.cargo/bin:$PATH' >> /etc/profile.d/cargo.sh && \ - echo 'export CARGO_HOME=/opt/.cargo' >> /etc/profile.d/cargo.sh && \ - echo 'export GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1' >> /etc/profile.d/cargo.sh; \ + chown -R 1001:0 /opt/.cargo; \If needed, set explicit
ENV PATH=/opt/.cargo/bin:$PATHin this stage when building.
252-257: Duplicate ARG TARGETARCH in the same stage.Declare it once per stage.
-FROM jupyter-minimal AS jupyter-datascience -ARG TARGETARCH +FROM jupyter-minimal AS jupyter-datascience ARG DATASCIENCE_SOURCE_CODE=jupyter/datascience/ubi9-python-3.12 -ARG OPENBLAS_VERSION=0.3.30 -ARG TARGETARCH +ARG OPENBLAS_VERSION=0.3.30 +ARG TARGETARCHOr keep a single
ARG TARGETARCHafter FROM and remove the other.
274-276: Redundant cache removal.
dnf clean allsuffices; removerm -rf /var/cache/yum.-RUN dnf install -y jq unixODBC unixODBC-devel postgresql git-lfs libsndfile libxcrypt-compat && \ - dnf clean all && rm -rf /var/cache/yum +RUN dnf install -y jq unixODBC unixODBC-devel postgresql git-lfs libsndfile libxcrypt-compat && \ + dnf clean all
97-101: Use TARGETARCH mapping for oc client, not $(uname -m).Cross-builds can fetch the wrong arch. Map BuildKit’s TARGETARCH to mirror names.
-RUN curl -L https://mirror.openshift.com/pub/openshift-v4/$(uname -m)/clients/ocp/stable/openshift-client-linux.tar.gz \ +ARG TARGETARCH +RUN case "$TARGETARCH" in amd64) OS_ARCH=x86_64;; arm64) OS_ARCH=aarch64;; ppc64le) OS_ARCH=ppc64le;; s390x) OS_ARCH=s390x;; *) echo "Unsupported arch: $TARGETARCH" >&2; exit 1;; esac && \ + curl -L "https://mirror.openshift.com/pub/openshift-v4/${OS_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.gz
49-54: Upgrade step: log skipped packages for auditability.Same suggestion as elsewhere to make skipped updates visible in CI logs.
1-10: Optional: consolidate builder-only toolchains.Nice split with common/onnx/openblas builders. Consider pushing toolchain install (gcc-toolset, cmake, ninja) solely into those builder stages to keep cpu-base lean on x86_64/aarch64 too.
jiridanek
force-pushed
the
datascience-jupyter-multiarch
branch
from
d1afff4 to
88e3af9
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu (2)
57-68: ppc64le lacks build toolchain/devel headers; C-extension builds may fail.Install minimal build deps on ppc64le (python3-devel, pybind11-devel, toolchain, openssl-devel) like s390x.
Apply:
RUN --mount=type=cache,target=/var/cache/dnf \ echo "Building for architecture: ${TARGETARCH}" && \ - if [ "$TARGETARCH" = "s390x" ]; then \ + if [ "$TARGETARCH" = "s390x" ]; then \ PACKAGES="perl mesa-libGL skopeo gcc gcc-c++ make openssl-devel autoconf automake libtool cmake python3-devel pybind11-devel openblas-devel unixODBC-devel"; \ - else \ + elif [ "$TARGETARCH" = "ppc64le" ]; then \ + PACKAGES="perl mesa-libGL skopeo gcc gcc-c++ make openssl-devel cmake python3-devel pybind11-devel unixODBC-devel"; \ + else \ PACKAGES="perl mesa-libGL skopeo"; \ fi && \
335-352: Ensure Cargo is on PATH during uv install (non-login shells won’t source profile.d).Prefix PATH in the s390x/ppc64le branches when running uv so Rust-based builds succeed.
Apply:
- if [ "$TARGETARCH" = "ppc64le" ] || [ "$TARGETARCH" = "s390x" ]; then \ + if [ "$TARGETARCH" = "ppc64le" ] || [ "$TARGETARCH" = "s390x" ]; then \ # We need special flags and environment variables when building packages - GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1 \ + PATH=/opt/.cargo/bin:$PATH \ + GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1 \ CFLAGS="-O3" CXXFLAGS="-O3" \ uv pip install --strict --no-deps --no-cache --no-config --no-progress \ --verify-hashes --compile-bytecode --index-strategy=unsafe-best-match \ --requirements=./pylock.toml; \
♻️ Duplicate comments (2)
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu (2)
294-306: Consume staged OpenBLAS; remove final-stage make install; run ldconfig.Avoid installing into /usr/local at runtime (source of “Permission denied”). Copy the staged files and refresh the linker cache.
Apply:
-# Copy OpenBLAS,ONNX wheels for Power -COPY --from=openblas-builder /root/OpenBLAS-${OPENBLAS_VERSION} /openblas +# Copy OpenBLAS (staged to /usr/local) and ONNX wheels for Power +COPY --from=openblas-builder /openblas-root/ / COPY --from=onnx-builder /root/onnx_wheel/ /onnxwheels/ @@ RUN <<'EOF' set -Eeuxo pipefail if [ "${TARGETARCH}" = "ppc64le" ]; then pip install /onnxwheels/*.whl else echo "Skipping ONNX/OpenBLAS install on non-Power" fi EOF @@ -USER root -RUN <<'EOF' -set -Eeuxo pipefail -if [ "${TARGETARCH}" = "ppc64le" ]; then - rm -rf /onnxwheels -else - echo "Skipping ONNX/OpenBLAS install on non-Power" -fi -EOF - -RUN <<'EOF' -set -Eeuxo pipefail -if [ "${TARGETARCH}" = "ppc64le" ]; then - PREFIX=/usr/local make -C /openblas install - rm -rf /openblas -else - echo "Skipping ONNX/OpenBLAS install on non-Power" -fi -EOF - -USER 1001:0 +USER root +RUN <<'EOF' +set -Eeuxo pipefail +if [ "${TARGETARCH}" = "ppc64le" ]; then + echo /usr/local/lib > /etc/ld.so.conf.d/usr-local.conf + ldconfig + rm -rf /onnxwheels +else + echo "Skipping OpenBLAS/ONNX cleanup on non-Power" +fi +EOF +USER 1001:0Also applies to: 318-326
206-221: Stage OpenBLAS install with DESTDIR and enable gcc-toolset during build (fix ppc64le permission failures).Build OpenBLAS in the builder and install into a staged root; don’t defer installation to the final stage. Also enable gcc-toolset-13 for a modern toolchain.
Apply:
FROM common-builder AS openblas-builder ARG TARGETARCH ARG OPENBLAS_VERSION=0.3.30 WORKDIR /root RUN <<'EOF' set -Eeuxo pipefail if [ "${TARGETARCH}" = "ppc64le" ]; then - 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 + wget https://github.com/OpenMathLib/OpenBLAS/releases/download/v${OPENBLAS_VERSION}/OpenBLAS-${OPENBLAS_VERSION}.zip + unzip OpenBLAS-${OPENBLAS_VERSION}.zip + cd OpenBLAS-${OPENBLAS_VERSION} + source /opt/rh/gcc-toolset-13/enable + make -j"$(nproc)" TARGET=POWER9 BINARY=64 USE_OPENMP=1 USE_THREAD=1 DYNAMIC_ARCH=1 INTERFACE64=0 + make -j"$(nproc)" PREFIX=/usr/local DESTDIR=/openblas-root install else - mkdir -p OpenBLAS-${OPENBLAS_VERSION} + mkdir -p /openblas-root echo "Skipping OpenBLAS build on non-Power" fi EOF
🧹 Nitpick comments (3)
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu (3)
115-161: Pin Arrow to a release tag for reproducible pyarrow wheels (avoid HEAD).Use a tagged release (e.g., apache-arrow-20.0.0) per prior s390x reproducibility guidance.
Apply:
- git clone --depth 1 https://github.com/apache/arrow.git && \ - cd arrow/cpp && \ + git clone --depth 1 --branch apache-arrow-20.0.0 https://github.com/apache/arrow.git && \ + cd arrow/cpp && \
253-258: Remove duplicate ARG TARGETARCH in this stage.Two ARG TARGETARCH lines back-to-back; keep a single declaration.
Apply:
FROM jupyter-minimal AS jupyter-datascience -ARG TARGETARCH @@ ARG DATASCIENCE_SOURCE_CODE=jupyter/datascience/ubi9-python-3.12 ARG OPENBLAS_VERSION=0.3.30 -ARG TARGETARCH
189-197: ONNX build: enable gcc-toolset and pin requirements for stability.You source gcc-toolset-13 (good). Consider pinning requirements via a constraints file to avoid transient breakage during pip wheel.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu(4 hunks)
🧰 Additional context used
🧠 Learnings (18)
📓 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#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T11:27:31.040Z
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#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T12:10:50.856Z
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.
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.856Z
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#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#2317
File: codeserver/ubi9-python-3.12/get_code_server_rpm.sh:31-37
Timestamp: 2025-09-05T13:16:48.754Z
Learning: jiridanek requested GitHub issue creation for build tools installation unification across builder images during PR #2317 review. Issue #2322 was created addressing inconsistent build dependency management patterns across different builder images, proposing multiple solution approaches including Development Tools group installation, centralized configuration, and layered approaches, with comprehensive acceptance criteria covering auditing, standardization, regression prevention, and multi-architecture support (x86_64, ppc64le, aarch64, s390x), continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:232-249
Timestamp: 2025-09-12T08:27:00.439Z
Learning: jiridanek requested GitHub issue creation for Rust toolchain availability during s390x builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2432 review. Issue #2435 was created addressing PATH availability problems where Rust/cargo installed in cpu-base stage at /opt/.cargo/bin may not be accessible during uv pip install step in jupyter-datascience stage, proposing three solution approaches: immediate environment variable fix, builder stage pattern following codeserver approach, and ENV declaration fix, with comprehensive acceptance criteria covering build reliability, multi-architecture compatibility, and alignment with established patterns, continuing the systematic infrastructure improvement tracking methodology.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:232-249
Timestamp: 2025-09-12T08:27:00.439Z
Learning: jiridanek requested GitHub issue creation for Rust toolchain availability during s390x builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2432 review. The issue addresses PATH availability problems where Rust/cargo installed in cpu-base stage at /opt/.cargo/bin may not be accessible during uv pip install step in jupyter-datascience stage, proposing three solution approaches: immediate environment variable fix, builder stage pattern following codeserver approach, and ENV declaration fix, with comprehensive acceptance criteria covering build reliability, multi-architecture compatibility, and alignment with established patterns, continuing the systematic infrastructure improvement tracking methodology.
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.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2227
File: codeserver/ubi9-python-3.12/Dockerfile.cpu:122-123
Timestamp: 2025-09-05T12:25:09.719Z
Learning: jiridanek requested GitHub issue creation for Docker multi-stage synchronization improvement in codeserver/ubi9-python-3.12/Dockerfile.cpu during PR #2227 review. The issue addresses sentinel file pattern using /tmp/control copied to /dev/null for stage coordination between rpm-base, whl-cache, and codeserver stages, proposing semantic improvements with descriptive file names, inline documentation, and elimination of /dev/null hack while maintaining multi-architecture build functionality for ppc64le support.
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#2432
File: jupyter/datascience/ubi9-python-3.12/pylock.toml:534-536
Timestamp: 2025-09-12T08:39:17.540Z
Learning: In the opendatahub-io/notebooks project, not all container images are s390x enabled yet. Images without platform markers (like `marker = "platform_machine != 's390x'"`) simply haven't been patched for s390x support yet, indicating a phased rollout approach for s390x enablement across different notebook images.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-09-10T21:01:46.464Z
Learning: jiridanek requested GitHub issue creation for banner comment documentation update in codeserver/ubi9-python-3.12/get_code_server_rpm.sh during PR #2356 review. Issue #2395 was created to update outdated banner comment that only mentioned ppc64le support when script now builds RPMs for amd64, arm64, and ppc64le architectures, with specific diff showing the required changes from lines 4-8, continuing the established pattern of systematic documentation 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.
📚 Learning: 2025-09-05T12:10:50.856Z
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.856Z
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.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T12:10:50.856Z
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.856Z
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.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T12:25:09.719Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2227
File: codeserver/ubi9-python-3.12/Dockerfile.cpu:122-123
Timestamp: 2025-09-05T12:25:09.719Z
Learning: jiridanek requested GitHub issue creation for Docker multi-stage synchronization improvement in codeserver/ubi9-python-3.12/Dockerfile.cpu during PR #2227 review. The issue addresses sentinel file pattern using /tmp/control copied to /dev/null for stage coordination between rpm-base, whl-cache, and codeserver stages, proposing semantic improvements with descriptive file names, inline documentation, and elimination of /dev/null hack while maintaining multi-architecture build functionality for ppc64le support.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-12T08:27:00.439Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:232-249
Timestamp: 2025-09-12T08:27:00.439Z
Learning: jiridanek requested GitHub issue creation for Rust toolchain availability during s390x builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2432 review. Issue #2435 was created addressing PATH availability problems where Rust/cargo installed in cpu-base stage at /opt/.cargo/bin may not be accessible during uv pip install step in jupyter-datascience stage, proposing three solution approaches: immediate environment variable fix, builder stage pattern following codeserver approach, and ENV declaration fix, with comprehensive acceptance criteria covering build reliability, multi-architecture compatibility, and alignment with established patterns, continuing the systematic infrastructure improvement tracking methodology.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-12T08:27:00.439Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:232-249
Timestamp: 2025-09-12T08:27:00.439Z
Learning: jiridanek requested GitHub issue creation for Rust toolchain availability during s390x builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2432 review. The issue addresses PATH availability problems where Rust/cargo installed in cpu-base stage at /opt/.cargo/bin may not be accessible during uv pip install step in jupyter-datascience stage, proposing three solution approaches: immediate environment variable fix, builder stage pattern following codeserver approach, and ENV declaration fix, with comprehensive acceptance criteria covering build reliability, multi-architecture compatibility, and alignment with established patterns, continuing the systematic infrastructure improvement tracking methodology.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T12:29:07.819Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2227
File: codeserver/ubi9-python-3.12/Dockerfile.cpu:218-218
Timestamp: 2025-09-05T12:29:07.819Z
Learning: jiridanek requested GitHub issue creation for uv multi-stage Docker build architectural investigation during PR #2227 review. The current implementation uses a three-stage build with whl-cache stage for wheel building/caching, base stage for OS setup, and final codeserver stage for offline installation using --offline flag and cache mounts. The pattern separates build phase (internet access, build tools) from install phase (offline, faster) while supporting multi-architecture builds (x86_64, ppc64le) with sentinel file coordination using /tmp/control files.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T11:27:31.040Z
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.040Z
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.
Applied to files:
jupyter/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:
jupyter/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:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-12T08:20:45.369Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:102-159
Timestamp: 2025-09-12T08:20:45.369Z
Learning: jiridanek requested GitHub issue creation for pyarrow build reproducibility improvement during PR #2432 review. Issue #2433 was created addressing HEAD builds causing reproducibility issues in s390x wheel-builder stage, proposing pinned apache-arrow-20.0.0 tag to match pylock.toml specification, with comprehensive problem description covering version mismatch risks, detailed solution with implementation steps, clear acceptance criteria for build consistency verification, and proper context linking to PR #2432 review comment, continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T13:16:48.754Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2317
File: codeserver/ubi9-python-3.12/get_code_server_rpm.sh:31-37
Timestamp: 2025-09-05T13:16:48.754Z
Learning: jiridanek requested GitHub issue creation for build tools installation unification across builder images during PR #2317 review. Issue #2322 was created addressing inconsistent build dependency management patterns across different builder images, proposing multiple solution approaches including Development Tools group installation, centralized configuration, and layered approaches, with comprehensive acceptance criteria covering auditing, standardization, regression prevention, and multi-architecture support (x86_64, ppc64le, aarch64, s390x), continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-10T21:24:07.914Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-09-10T21:24:07.914Z
Learning: jiridanek requested GitHub issue creation for Docker chown optimization in codeserver/ubi9-python-3.12/Dockerfile.cpu during PR #2356 review. Issue #2403 was created addressing performance impact of broad recursive chown on entire /opt/app-root directory (line 235), proposing three solution approaches: scoped chown targeting specific changed paths, root cause fix during file creation, and test modification for permission validation, with detailed benefits analysis covering layer size reduction and build time optimization, continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Applied to files:
jupyter/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:
jupyter/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:
jupyter/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:
jupyter/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:
jupyter/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:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: build (jupyter-datascience-ubi9-python-3.12, 3.12, linux/ppc64le, false) / build
- GitHub Check: build (jupyter-datascience-ubi9-python-3.12, 3.12, linux/amd64, false) / build
🔇 Additional comments (1)
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu (1)
69-82: Rust needed for ppc64le (rpds-py / other Rust-backed packages)Dockerfile installs Rust only for s390x (jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu lines 69–82); ppc64le builds may also require Rust (e.g., rpds-py). Either install Rust for ppc64le (prefer builder-provided toolchain and copy /opt/.cargo into the stage) or pin packages to wheel-supported versions — otherwise builds on ppc64le will fail.
To confirm, run from the repo root:
# search for Rust-backed Python packages and lockfiles rg -nP 'rpds(-|_)?py|maturin|pyo3|setuptools-rust' -S -C2 || true rg -n --hidden --no-ignore -S 'pyproject\.toml|requirements(\.txt)?|poetry.lock|pipfile.lock|Pipfile' || true
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu (2)
206-221: Install OpenBLAS in builder with DESTDIR; avoid make install in final stage.This addresses the ppc64le “Permission denied” failures during install into /usr/local and eliminates rebuilds in the final stage.
- 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 + cd OpenBLAS-${OPENBLAS_VERSION} + source /opt/rh/gcc-toolset-13/enable + make -j"$(nproc)" TARGET=POWER9 BINARY=64 USE_OPENMP=1 USE_THREAD=1 NUM_THREADS=120 DYNAMIC_ARCH=1 INTERFACE64=0 + make -j"$(nproc)" PREFIX=/usr/local DESTDIR=/openblas-root install
294-307: Consume staged OpenBLAS; drop install-from-source in final stage.Copy the preinstalled files and run ldconfig. Removes the root/permission-sensitive build in final layer.
-# Copy OpenBLAS,ONNX wheels for Power -COPY --from=openblas-builder /root/OpenBLAS-${OPENBLAS_VERSION} /openblas +# Copy OpenBLAS (staged to /usr/local inside builder) and ONNX wheels for Power +COPY --from=openblas-builder /openblas-root/ / COPY --from=onnx-builder /root/onnx_wheel/ /onnxwheels/ @@ -RUN <<'EOF' -set -Eeuxo pipefail -if [ "${TARGETARCH}" = "ppc64le" ]; then - PREFIX=/usr/local make -C /openblas install - rm -rf /openblas -else - echo "Skipping ONNX/OpenBLAS install on non-Power" -fi -EOF +USER root +RUN echo /usr/local/lib >/etc/ld.so.conf.d/usr-local.conf && ldconfig || true +USER 1001:0Also applies to: 318-326
🧹 Nitpick comments (7)
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu (7)
253-258: Remove duplicate ARG TARGETARCH in this stage.Defined twice (Line 253 and Line 257). Keep one.
ARG TARGETARCH @@ -ARG OPENBLAS_VERSION=0.3.30 -ARG TARGETARCH +ARG OPENBLAS_VERSION=0.3.30
115-161: Align pyarrow build to pinned Arrow tag (or make it configurable).You’re cloning apache-arrow-17.0.0. Prior work suggested pinning to 20.0.0 for reproducibility. Either switch to that tag or make it an ARG with a sane default, then use it here.
-FROM cpu-base AS pyarrow-builder +FROM cpu-base AS pyarrow-builder ARG TARGETARCH USER 0 WORKDIR /tmp/build-wheels @@ - git clone --depth 1 --branch "apache-arrow-17.0.0" https://github.com/apache/arrow.git && \ + ARG ARROW_TAG=apache-arrow-20.0.0 && \ + git clone --depth 1 --branch "${ARROW_TAG}" https://github.com/apache/arrow.git && \
284-285: PKG_CONFIG_PATH should include lib64 on RHEL-based ppc64le.Ensure pkg-config finds .pc files under /usr/local/lib64/pkgconfig as well.
-ENV PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/ +ENV PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig:/usr/local/lib/pkgconfig
171-176: Use gcc-toolset compilers consistently.You install gcc-toolset-13 here but did not enable it in the OpenBLAS builder originally. The DESTDIR fix adds sourcing; keep this consistent across all Power builds.
216-216: Avoid hardcoding NUM_THREADS=120.This oversubscribes typical CI runners. Prefer OMP_NUM_THREADS or a smaller cap (e.g., 8–16) to reduce flakiness.
-make -j"$(nproc)" TARGET=POWER9 BINARY=64 USE_OPENMP=1 USE_THREAD=1 NUM_THREADS=120 DYNAMIC_ARCH=1 INTERFACE64=0 +make -j"$(nproc)" TARGET=POWER9 BINARY=64 USE_OPENMP=1 USE_THREAD=1 NUM_THREADS=${OPENBLAS_THREADS:-16} DYNAMIC_ARCH=1 INTERFACE64=0
335-352: Hash-verification with uv may fail on ppc64le/s390x when building from sdist.You still pass --verify-hashes under arches that often build from source. Consider gating it off for those arches or ensure pylock includes sdist hashes.
295-297: Add checksum verification for downloaded artifacts.Validate the integrity of ONNX/OpenBLAS sources (sha256 or GPG) to reduce supply-chain risk.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu(4 hunks)
🧰 Additional context used
🧠 Learnings (18)
📓 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#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T11:27:31.040Z
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#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T12:10:50.856Z
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.
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.856Z
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#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#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:232-249
Timestamp: 2025-09-12T08:27:00.439Z
Learning: jiridanek requested GitHub issue creation for Rust toolchain availability during s390x builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2432 review. Issue #2435 was created addressing PATH availability problems where Rust/cargo installed in cpu-base stage at /opt/.cargo/bin may not be accessible during uv pip install step in jupyter-datascience stage, proposing three solution approaches: immediate environment variable fix, builder stage pattern following codeserver approach, and ENV declaration fix, with comprehensive acceptance criteria covering build reliability, multi-architecture compatibility, and alignment with established patterns, continuing the systematic infrastructure improvement tracking methodology.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:232-249
Timestamp: 2025-09-12T08:27:00.439Z
Learning: jiridanek requested GitHub issue creation for Rust toolchain availability during s390x builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2432 review. The issue addresses PATH availability problems where Rust/cargo installed in cpu-base stage at /opt/.cargo/bin may not be accessible during uv pip install step in jupyter-datascience stage, proposing three solution approaches: immediate environment variable fix, builder stage pattern following codeserver approach, and ENV declaration fix, with comprehensive acceptance criteria covering build reliability, multi-architecture compatibility, and alignment with established patterns, continuing the systematic infrastructure improvement tracking methodology.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2317
File: codeserver/ubi9-python-3.12/get_code_server_rpm.sh:31-37
Timestamp: 2025-09-05T13:16:48.754Z
Learning: jiridanek requested GitHub issue creation for build tools installation unification across builder images during PR #2317 review. Issue #2322 was created addressing inconsistent build dependency management patterns across different builder images, proposing multiple solution approaches including Development Tools group installation, centralized configuration, and layered approaches, with comprehensive acceptance criteria covering auditing, standardization, regression prevention, and multi-architecture support (x86_64, ppc64le, aarch64, s390x), continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
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.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2227
File: codeserver/ubi9-python-3.12/Dockerfile.cpu:122-123
Timestamp: 2025-09-05T12:25:09.719Z
Learning: jiridanek requested GitHub issue creation for Docker multi-stage synchronization improvement in codeserver/ubi9-python-3.12/Dockerfile.cpu during PR #2227 review. The issue addresses sentinel file pattern using /tmp/control copied to /dev/null for stage coordination between rpm-base, whl-cache, and codeserver stages, proposing semantic improvements with descriptive file names, inline documentation, and elimination of /dev/null hack while maintaining multi-architecture build functionality for ppc64le support.
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#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#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.
📚 Learning: 2025-09-05T12:10:50.856Z
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.856Z
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.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T12:10:50.856Z
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.856Z
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.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-12T08:27:00.439Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:232-249
Timestamp: 2025-09-12T08:27:00.439Z
Learning: jiridanek requested GitHub issue creation for Rust toolchain availability during s390x builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2432 review. Issue #2435 was created addressing PATH availability problems where Rust/cargo installed in cpu-base stage at /opt/.cargo/bin may not be accessible during uv pip install step in jupyter-datascience stage, proposing three solution approaches: immediate environment variable fix, builder stage pattern following codeserver approach, and ENV declaration fix, with comprehensive acceptance criteria covering build reliability, multi-architecture compatibility, and alignment with established patterns, continuing the systematic infrastructure improvement tracking methodology.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-12T08:27:00.439Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:232-249
Timestamp: 2025-09-12T08:27:00.439Z
Learning: jiridanek requested GitHub issue creation for Rust toolchain availability during s390x builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2432 review. The issue addresses PATH availability problems where Rust/cargo installed in cpu-base stage at /opt/.cargo/bin may not be accessible during uv pip install step in jupyter-datascience stage, proposing three solution approaches: immediate environment variable fix, builder stage pattern following codeserver approach, and ENV declaration fix, with comprehensive acceptance criteria covering build reliability, multi-architecture compatibility, and alignment with established patterns, continuing the systematic infrastructure improvement tracking methodology.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T12:25:09.719Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2227
File: codeserver/ubi9-python-3.12/Dockerfile.cpu:122-123
Timestamp: 2025-09-05T12:25:09.719Z
Learning: jiridanek requested GitHub issue creation for Docker multi-stage synchronization improvement in codeserver/ubi9-python-3.12/Dockerfile.cpu during PR #2227 review. The issue addresses sentinel file pattern using /tmp/control copied to /dev/null for stage coordination between rpm-base, whl-cache, and codeserver stages, proposing semantic improvements with descriptive file names, inline documentation, and elimination of /dev/null hack while maintaining multi-architecture build functionality for ppc64le support.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T12:29:07.819Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2227
File: codeserver/ubi9-python-3.12/Dockerfile.cpu:218-218
Timestamp: 2025-09-05T12:29:07.819Z
Learning: jiridanek requested GitHub issue creation for uv multi-stage Docker build architectural investigation during PR #2227 review. The current implementation uses a three-stage build with whl-cache stage for wheel building/caching, base stage for OS setup, and final codeserver stage for offline installation using --offline flag and cache mounts. The pattern separates build phase (internet access, build tools) from install phase (offline, faster) while supporting multi-architecture builds (x86_64, ppc64le) with sentinel file coordination using /tmp/control files.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-12T08:20:45.369Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:102-159
Timestamp: 2025-09-12T08:20:45.369Z
Learning: jiridanek requested GitHub issue creation for pyarrow build reproducibility improvement during PR #2432 review. Issue #2433 was created addressing HEAD builds causing reproducibility issues in s390x wheel-builder stage, proposing pinned apache-arrow-20.0.0 tag to match pylock.toml specification, with comprehensive problem description covering version mismatch risks, detailed solution with implementation steps, clear acceptance criteria for build consistency verification, and proper context linking to PR #2432 review comment, continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T11:27:31.040Z
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.040Z
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.
Applied to files:
jupyter/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:
jupyter/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:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T13:16:48.754Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2317
File: codeserver/ubi9-python-3.12/get_code_server_rpm.sh:31-37
Timestamp: 2025-09-05T13:16:48.754Z
Learning: jiridanek requested GitHub issue creation for build tools installation unification across builder images during PR #2317 review. Issue #2322 was created addressing inconsistent build dependency management patterns across different builder images, proposing multiple solution approaches including Development Tools group installation, centralized configuration, and layered approaches, with comprehensive acceptance criteria covering auditing, standardization, regression prevention, and multi-architecture support (x86_64, ppc64le, aarch64, s390x), continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-10T21:24:07.914Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-09-10T21:24:07.914Z
Learning: jiridanek requested GitHub issue creation for Docker chown optimization in codeserver/ubi9-python-3.12/Dockerfile.cpu during PR #2356 review. Issue #2403 was created addressing performance impact of broad recursive chown on entire /opt/app-root directory (line 235), proposing three solution approaches: scoped chown targeting specific changed paths, root cause fix during file creation, and test modification for permission validation, with detailed benefits analysis covering layer size reduction and build time optimization, continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Applied to files:
jupyter/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:
jupyter/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:
jupyter/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:
jupyter/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:
jupyter/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:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
🪛 GitHub Actions: Code static analysis
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
[error] 222-222: Parse error: unexpected '#' - hadolint: expected a new line followed by the next instruction
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: build (jupyter-datascience-ubi9-python-3.12, 3.12, linux/ppc64le, false) / build
- GitHub Check: build (jupyter-datascience-ubi9-python-3.12, 3.12, linux/amd64, false) / build
- GitHub Check: Red Hat Konflux / odh-workbench-jupyter-datascience-cpu-py312-ubi9-on-pull-request
🔇 Additional comments (2)
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu (2)
299-306: Install ONNX after OpenBLAS is present (order), or confirm no linkage is required.If ONNX or its deps need BLAS at build/import time, install OpenBLAS first (with the staged copy) then pip install ONNX. Otherwise, please confirm it’s safe.
99-103: Verify oc client arch resolution.$(uname -m) should reflect TARGETARCH under buildx/buildah, but please confirm for Konflux. If mismatched, switch to TARGETARCH mapping (amd64→x86_64, arm64→aarch64, ppc64le, s390x).
| echo "Skipping OpenBLAS build on non-Power" | ||
| fi | ||
| EOF | ||
| #################### |
There was a problem hiding this comment.
Fix hadolint parse error (heredoc compatibility).
hadolint chokes on the heredoc just above this line. Replace heredocs with a single RUN using bash -lc (or unquote markers across the file). Minimal fix for the failing block shown below.
-FROM common-builder AS openblas-builder
-ARG TARGETARCH
-ARG OPENBLAS_VERSION=0.3.30
-WORKDIR /root
-RUN <<'EOF'
-set -Eeuxo pipefail
-if [ "${TARGETARCH}" = "ppc64le" ]; then
- 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
- mkdir -p OpenBLAS-${OPENBLAS_VERSION}
- echo "Skipping OpenBLAS build on non-Power"
-fi
-EOF
+FROM common-builder AS openblas-builder
+ARG TARGETARCH
+ARG OPENBLAS_VERSION=0.3.30
+WORKDIR /root
+RUN bash -lc 'set -Eeuxo pipefail; \
+ if [ "${TARGETARCH}" = "ppc64le" ]; then \
+ wget https://github.com/OpenMathLib/OpenBLAS/releases/download/v${OPENBLAS_VERSION}/OpenBLAS-${OPENBLAS_VERSION}.zip; \
+ unzip OpenBLAS-${OPENBLAS_VERSION}.zip; \
+ cd OpenBLAS-${OPENBLAS_VERSION}; \
+ source /opt/rh/gcc-toolset-13/enable; \
+ make -j"$(nproc)" TARGET=POWER9 BINARY=64 USE_OPENMP=1 USE_THREAD=1 NUM_THREADS=120 DYNAMIC_ARCH=1 INTERFACE64=0; \
+ else \
+ mkdir -p OpenBLAS-${OPENBLAS_VERSION}; \
+ echo "Skipping OpenBLAS build on non-Power"; \
+ 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
| #################### | |
| FROM common-builder AS openblas-builder | |
| ARG TARGETARCH | |
| ARG OPENBLAS_VERSION=0.3.30 | |
| WORKDIR /root | |
| RUN bash -lc 'set -Eeuxo pipefail; \ | |
| if [ "${TARGETARCH}" = "ppc64le" ]; then \ | |
| wget https://github.com/OpenMathLib/OpenBLAS/releases/download/v${OPENBLAS_VERSION}/OpenBLAS-${OPENBLAS_VERSION}.zip; \ | |
| unzip OpenBLAS-${OPENBLAS_VERSION}.zip; \ | |
| cd OpenBLAS-${OPENBLAS_VERSION}; \ | |
| source /opt/rh/gcc-toolset-13/enable; \ | |
| make -j"$(nproc)" TARGET=POWER9 BINARY=64 USE_OPENMP=1 USE_THREAD=1 NUM_THREADS=120 DYNAMIC_ARCH=1 INTERFACE64=0; \ | |
| else \ | |
| mkdir -p OpenBLAS-${OPENBLAS_VERSION}; \ | |
| echo "Skipping OpenBLAS build on non-Power"; \ | |
| fi' |
🧰 Tools
🪛 GitHub Actions: Code static analysis
[error] 222-222: Parse error: unexpected '#' - hadolint: expected a new line followed by the next instruction
🤖 Prompt for AI Agents
In jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu around line 222, hadolint
fails parsing the heredoc used just above this line; replace that heredoc block
with a single RUN that executes the same commands via bash -lc (or alternatively
unquote heredoc markers across the file). Edit the Dockerfile to remove the
multiline heredoc block and consolidate its commands into one RUN "bash -lc
'...'" invocation (preserving commands, environment variables and redirects),
ensuring any inner quotes are escaped or use a single outer quoting strategy so
the shell executes identically while hadolint can parse it.
…eview (cherry picked from commit 42493f4) * https://github.com/opendatahub-io/notebooks/pull/2286/commits
…ch-jupyter-datascience-cpu-py312-ubi9
We can't yet install devel library from c9s/rhel9, so we have to compile.
```
× Failed to build `pyarrow==17.0.0`
├─▶ The build backend returned an error
╰─▶ Call to `setuptools.build_meta.build_wheel` failed (exit status: 1)
```
...
```
CMake Error at CMakeLists.txt:266 (find_package):
By not providing "FindArrow.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Arrow", but
CMake did not find one.
Could not find a package configuration file provided by "Arrow" with any of
the following names:
ArrowConfig.cmake
arrow-config.cmake
```
7 tasks
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: atheo89 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Successful Konflux build Now will fix the rabbit reported issue. |
jiridanek
force-pushed
the
datascience-jupyter-multiarch
branch
from
501644f to
3d48c30
Compare
|
New changes are detected. LGTM label has been removed. |
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu (1)
115-161: Install git in pyarrow-builder and make Arrow tag configurablegit is not installed in pyarrow-builder (jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu RUN ~lines 115–161) but the build runs git clone — build will fail on ppc64le/s390x. Add git to the dnf install and introduce ARG ARROW_TAG (default apache-arrow-17.0.0) and use it in the clone. Most pylock.toml files pin pyarrow 17.0.0; jupyter/trustyai (and rocm/trustyai) pin pyarrow 20.0.0 — ensure ARROW_TAG matches the intended lockfile.
Apply:
@@ RUN --mount=type=cache,target=/root/.cache/pip \ --mount=type=cache,target=/root/.cache/dnf \ + ARG ARROW_TAG=apache-arrow-17.0.0 \ if [ "$TARGETARCH" = "ppc64le" ] || [ "$TARGETARCH" = "s390x" ]; then \ - dnf install -y cmake make gcc-c++ pybind11-devel wget && \ + dnf install -y cmake make gcc-c++ pybind11-devel wget git && \ dnf clean all && \ - git clone --depth 1 --branch "apache-arrow-17.0.0" https://github.com/apache/arrow.git && \ + git clone --depth 1 --branch "${ARROW_TAG}" https://github.com/apache/arrow.git && \
♻️ Duplicate comments (4)
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu (4)
206-221: Stage OpenBLAS install in builder via DESTDIR (then copy in final).Install into a DESTDIR in builder to avoid permission issues and drop make install from the final stage.
Apply:
FROM common-builder AS openblas-builder ARG TARGETARCH ARG OPENBLAS_VERSION=0.3.30 WORKDIR /root -RUN <<'EOF' -set -Eeuxo pipefail -if [ "${TARGETARCH}" = "ppc64le" ]; then - 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 - mkdir -p OpenBLAS-${OPENBLAS_VERSION} - echo "Skipping OpenBLAS build on non-Power" -fi -EOF +RUN bash -lc 'set -Eeuxo pipefail; \ + if [ "${TARGETARCH}" = "ppc64le" ]; then \ + wget https://github.com/OpenMathLib/OpenBLAS/releases/download/v${OPENBLAS_VERSION}/OpenBLAS-${OPENBLAS_VERSION}.zip; \ + unzip OpenBLAS-${OPENBLAS_VERSION}.zip; \ + cd OpenBLAS-${OPENBLAS_VERSION}; \ + source /opt/rh/gcc-toolset-13/enable; \ + make -j"$(nproc)" TARGET=POWER9 BINARY=64 USE_OPENMP=1 USE_THREAD=1 NUM_THREADS="$(nproc)" DYNAMIC_ARCH=1 INTERFACE64=0; \ + make -j"$(nproc)" PREFIX=/usr/local DESTDIR=/openblas-root install; \ + else \ + mkdir -p /openblas-root; \ + echo "Skipping OpenBLAS build on non-Power"; \ + fi'
294-326: Consume staged OpenBLAS from builder; remove make install in final and run ldconfig.Finish the DESTDIR pattern by copying the installed tree and dropping the fragile make step. Also ensure linker cache sees /usr/local/lib.
Apply:
-# Copy OpenBLAS,ONNX wheels for Power -COPY --from=openblas-builder /root/OpenBLAS-${OPENBLAS_VERSION} /openblas +# Copy OpenBLAS (staged install) and ONNX wheels for Power +COPY --from=openblas-builder /openblas-root/ / COPY --from=onnx-builder /root/onnx_wheel/ /onnxwheels/ @@ -# Power-specific ONNX/OpenBLAS installation -RUN <<'EOF' -set -Eeuxo pipefail -if [ "${TARGETARCH}" = "ppc64le" ]; then - pip install /onnxwheels/*.whl -else - echo "Skipping ONNX/OpenBLAS install on non-Power" -fi -EOF +# Power-specific ONNX installation +RUN bash -lc 'set -Eeuxo pipefail; \ + if [ "${TARGETARCH}" = "ppc64le" ]; then \ + pip install /onnxwheels/*.whl; \ + else \ + echo "Skipping ONNX install on non-Power"; \ + fi' @@ -USER root -RUN <<'EOF' -set -Eeuxo pipefail -if [ "${TARGETARCH}" = "ppc64le" ]; then - rm -rf /onnxwheels -else - echo "Skipping ONNX/OpenBLAS install on non-Power" -fi -EOF +USER root +RUN bash -lc 'set -Eeuxo pipefail; \ + if [ "${TARGETARCH}" = "ppc64le" ]; then rm -rf /onnxwheels; else echo "Skipping ONNX cleanup on non-Power"; fi' @@ -RUN <<'EOF' -set -Eeuxo pipefail -if [ "${TARGETARCH}" = "ppc64le" ]; then - PREFIX=/usr/local make -C /openblas install - rm -rf /openblas -else - echo "Skipping ONNX/OpenBLAS install on non-Power" -fi -EOF +# Ensure dynamic linker sees /usr/local/lib +RUN bash -lc 'echo /usr/local/lib > /etc/ld.so.conf.d/usr-local.conf && ldconfig || true'
169-177: Replace heredoc with bash -lc to satisfy hadolint.CI shows hadolint parse error around here. Converting heredocs to a single RUN with bash fixes it.
Apply:
FROM cpu-base AS common-builder ARG TARGETARCH USER root -RUN <<'EOF' -set -Eeuxo pipefail -if [ "${TARGETARCH}" = "ppc64le" ]; then - dnf install -y gcc-toolset-13 cmake ninja-build git wget unzip - dnf clean all -else - echo "Skipping common-builder package install on non-Power" -fi -EOF +RUN bash -lc 'set -Eeuxo pipefail; \ + if [ "${TARGETARCH}" = "ppc64le" ]; then \ + dnf install -y gcc-toolset-13 cmake ninja-build git wget unzip; \ + dnf clean all; \ + else \ + echo "Skipping common-builder package install on non-Power"; \ + fi'
186-201: Also convert this heredoc to bash -lc.Same parser issue risk as above; keep style consistent across stages.
Apply:
WORKDIR /root -RUN <<'EOF' -set -Eeuxo pipefail -if [ "${TARGETARCH}" = "ppc64le" ]; then - source /opt/rh/gcc-toolset-13/enable - git clone --recursive https://github.com/onnx/onnx.git - cd onnx - git checkout ${ONNX_VERSION} - git submodule update --init --recursive - pip install -r requirements.txt - export CMAKE_ARGS="-DPython3_EXECUTABLE=$(which python3.12)" - pip wheel . -w /root/onnx_wheel -else - echo "Skipping ONNX build on non-Power" - mkdir -p /root/onnx_wheel -fi -EOF +RUN bash -lc 'set -Eeuxo pipefail; \ + if [ "${TARGETARCH}" = "ppc64le" ]; then \ + source /opt/rh/gcc-toolset-13/enable; \ + git clone --recursive https://github.com/onnx/onnx.git; \ + cd onnx; \ + git checkout ${ONNX_VERSION}; \ + git submodule update --init --recursive; \ + pip install -r requirements.txt; \ + export CMAKE_ARGS="-DPython3_EXECUTABLE=$(which python3.12)"; \ + pip wheel . -w /root/onnx_wheel; \ + else \ + echo "Skipping ONNX build on non-Power"; \ + mkdir -p /root/onnx_wheel; \ + fi'
🧹 Nitpick comments (4)
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu (4)
249-251: Typo in section header.“jupytyer” → “jupyter”.
Apply:
-######################## -# jupytyer-datascience # -######################## +####################### +# jupyter-datascience # +#######################
253-258: Drop duplicate ARG TARGETARCH.TARGETARCH is declared twice in this stage.
Apply:
FROM jupyter-minimal AS jupyter-datascience ARG TARGETARCH @@ ARG DATASCIENCE_SOURCE_CODE=jupyter/datascience/ubi9-python-3.12 ARG OPENBLAS_VERSION=0.3.30 -ARG TARGETARCH
299-306: Standardize remaining heredocs in this stage.Convert these heredocs to bash -lc like above for consistency and linting.
Also applies to: 309-316, 318-326
331-352: Cargo on s390x may be missing from PATH in this stage.Per prior issue on Rust toolchain visibility, add PATH/CARGO_HOME so uv can build Rust deps on s390x without relying on profile.d sourcing.
Apply:
@@ -ENV PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/ +ENV PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/ \ + PATH=/opt/.cargo/bin:$PATH \ + CARGO_HOME=/opt/.cargoThis is safe across arches; the dirs just won’t exist elsewhere.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
.tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-pull-request.yaml(1 hunks)ci/cached-builds/gen_gha_matrix_jobs.py(4 hunks)jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu(4 hunks)scripts/generate_pull_request_pipelineruns.py(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- scripts/generate_pull_request_pipelineruns.py
- .tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-pull-request.yaml
- ci/cached-builds/gen_gha_matrix_jobs.py
🧰 Additional context used
🧠 Learnings (21)
📓 Common learnings
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2460
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:206-221
Timestamp: 2025-09-16T10:39:23.268Z
Learning: jiridanek requested GitHub issue creation for OpenBLAS installation staging during ppc64le builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2460 review. Issue #2466 was created addressing permission errors where OpenBLAS make install fails when attempting to write to /usr/local system paths from USER 1001 context in final stage, proposing DESTDIR staging pattern to build and install OpenBLAS artifacts within openblas-builder stage then COPY pre-installed files to final stage, with comprehensive problem description covering specific permission denied errors, detailed technical solution with code examples, clear acceptance criteria for build reliability and multi-architecture compatibility, and proper context linking to PR #2460 review comment, continuing the systematic infrastructure improvement tracking methodology for Power architecture support.
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#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T11:27:31.040Z
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#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T12:10:50.856Z
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.
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.856Z
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#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#2317
File: codeserver/ubi9-python-3.12/get_code_server_rpm.sh:31-37
Timestamp: 2025-09-05T13:16:48.754Z
Learning: jiridanek requested GitHub issue creation for build tools installation unification across builder images during PR #2317 review. Issue #2322 was created addressing inconsistent build dependency management patterns across different builder images, proposing multiple solution approaches including Development Tools group installation, centralized configuration, and layered approaches, with comprehensive acceptance criteria covering auditing, standardization, regression prevention, and multi-architecture support (x86_64, ppc64le, aarch64, s390x), continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:232-249
Timestamp: 2025-09-12T08:27:00.439Z
Learning: jiridanek requested GitHub issue creation for Rust toolchain availability during s390x builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2432 review. Issue #2435 was created addressing PATH availability problems where Rust/cargo installed in cpu-base stage at /opt/.cargo/bin may not be accessible during uv pip install step in jupyter-datascience stage, proposing three solution approaches: immediate environment variable fix, builder stage pattern following codeserver approach, and ENV declaration fix, with comprehensive acceptance criteria covering build reliability, multi-architecture compatibility, and alignment with established patterns, continuing the systematic infrastructure improvement tracking methodology.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:232-249
Timestamp: 2025-09-12T08:27:00.439Z
Learning: jiridanek requested GitHub issue creation for Rust toolchain availability during s390x builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2432 review. The issue addresses PATH availability problems where Rust/cargo installed in cpu-base stage at /opt/.cargo/bin may not be accessible during uv pip install step in jupyter-datascience stage, proposing three solution approaches: immediate environment variable fix, builder stage pattern following codeserver approach, and ENV declaration fix, with comprehensive acceptance criteria covering build reliability, multi-architecture compatibility, and alignment with established patterns, continuing the systematic infrastructure improvement tracking methodology.
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.
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#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#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.
📚 Learning: 2025-09-16T10:39:23.268Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2460
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:206-221
Timestamp: 2025-09-16T10:39:23.268Z
Learning: jiridanek requested GitHub issue creation for OpenBLAS installation staging during ppc64le builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2460 review. Issue #2466 was created addressing permission errors where OpenBLAS make install fails when attempting to write to /usr/local system paths from USER 1001 context in final stage, proposing DESTDIR staging pattern to build and install OpenBLAS artifacts within openblas-builder stage then COPY pre-installed files to final stage, with comprehensive problem description covering specific permission denied errors, detailed technical solution with code examples, clear acceptance criteria for build reliability and multi-architecture compatibility, and proper context linking to PR #2460 review comment, continuing the systematic infrastructure improvement tracking methodology for Power architecture support.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T12:10:50.856Z
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.856Z
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.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T12:10:50.856Z
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.856Z
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.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-12T08:27:00.439Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:232-249
Timestamp: 2025-09-12T08:27:00.439Z
Learning: jiridanek requested GitHub issue creation for Rust toolchain availability during s390x builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2432 review. Issue #2435 was created addressing PATH availability problems where Rust/cargo installed in cpu-base stage at /opt/.cargo/bin may not be accessible during uv pip install step in jupyter-datascience stage, proposing three solution approaches: immediate environment variable fix, builder stage pattern following codeserver approach, and ENV declaration fix, with comprehensive acceptance criteria covering build reliability, multi-architecture compatibility, and alignment with established patterns, continuing the systematic infrastructure improvement tracking methodology.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-12T08:27:00.439Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:232-249
Timestamp: 2025-09-12T08:27:00.439Z
Learning: jiridanek requested GitHub issue creation for Rust toolchain availability during s390x builds in jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu during PR #2432 review. The issue addresses PATH availability problems where Rust/cargo installed in cpu-base stage at /opt/.cargo/bin may not be accessible during uv pip install step in jupyter-datascience stage, proposing three solution approaches: immediate environment variable fix, builder stage pattern following codeserver approach, and ENV declaration fix, with comprehensive acceptance criteria covering build reliability, multi-architecture compatibility, and alignment with established patterns, continuing the systematic infrastructure improvement tracking methodology.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T12:25:09.719Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2227
File: codeserver/ubi9-python-3.12/Dockerfile.cpu:122-123
Timestamp: 2025-09-05T12:25:09.719Z
Learning: jiridanek requested GitHub issue creation for Docker multi-stage synchronization improvement in codeserver/ubi9-python-3.12/Dockerfile.cpu during PR #2227 review. The issue addresses sentinel file pattern using /tmp/control copied to /dev/null for stage coordination between rpm-base, whl-cache, and codeserver stages, proposing semantic improvements with descriptive file names, inline documentation, and elimination of /dev/null hack while maintaining multi-architecture build functionality for ppc64le support.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T12:29:07.819Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2227
File: codeserver/ubi9-python-3.12/Dockerfile.cpu:218-218
Timestamp: 2025-09-05T12:29:07.819Z
Learning: jiridanek requested GitHub issue creation for uv multi-stage Docker build architectural investigation during PR #2227 review. The current implementation uses a three-stage build with whl-cache stage for wheel building/caching, base stage for OS setup, and final codeserver stage for offline installation using --offline flag and cache mounts. The pattern separates build phase (internet access, build tools) from install phase (offline, faster) while supporting multi-architecture builds (x86_64, ppc64le) with sentinel file coordination using /tmp/control files.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T11:27:31.040Z
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.040Z
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.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-12T08:20:45.369Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2432
File: jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu:102-159
Timestamp: 2025-09-12T08:20:45.369Z
Learning: jiridanek requested GitHub issue creation for pyarrow build reproducibility improvement during PR #2432 review. Issue #2433 was created addressing HEAD builds causing reproducibility issues in s390x wheel-builder stage, proposing pinned apache-arrow-20.0.0 tag to match pylock.toml specification, with comprehensive problem description covering version mismatch risks, detailed solution with implementation steps, clear acceptance criteria for build consistency verification, and proper context linking to PR #2432 review comment, continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Applied to files:
jupyter/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:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-10T21:24:07.914Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-09-10T21:24:07.914Z
Learning: jiridanek requested GitHub issue creation for Docker chown optimization in codeserver/ubi9-python-3.12/Dockerfile.cpu during PR #2356 review. Issue #2403 was created addressing performance impact of broad recursive chown on entire /opt/app-root directory (line 235), proposing three solution approaches: scoped chown targeting specific changed paths, root cause fix during file creation, and test modification for permission validation, with detailed benefits analysis covering layer size reduction and build time optimization, continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T13:16:48.754Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2317
File: codeserver/ubi9-python-3.12/get_code_server_rpm.sh:31-37
Timestamp: 2025-09-05T13:16:48.754Z
Learning: jiridanek requested GitHub issue creation for build tools installation unification across builder images during PR #2317 review. Issue #2322 was created addressing inconsistent build dependency management patterns across different builder images, proposing multiple solution approaches including Development Tools group installation, centralized configuration, and layered approaches, with comprehensive acceptance criteria covering auditing, standardization, regression prevention, and multi-architecture support (x86_64, ppc64le, aarch64, s390x), continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Applied to files:
jupyter/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:
jupyter/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:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T07:46:50.781Z
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.
Applied to files:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
📚 Learning: 2025-09-05T07:46:50.781Z
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.
Applied to files:
jupyter/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:
jupyter/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:
jupyter/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:
jupyter/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:
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
🪛 GitHub Actions: Code static analysis
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu
[error] 222-222: Hadolint: unexpected '#' at line 222:1; expecting a new line followed by the next instruction.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: build (jupyter-datascience-ubi9-python-3.12, 3.12, linux/ppc64le, false) / build
- GitHub Check: build (jupyter-datascience-ubi9-python-3.12, 3.12, linux/amd64, false) / build
- GitHub Check: Red Hat Konflux / odh-workbench-jupyter-datascience-cpu-py312-ubi9-on-pull-request
🔇 Additional comments (2)
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpu (2)
274-277: LGTM: extra OS deps for datascience.unixODBC(+devel), jq, libsndfile, etc., look correct for this image.
284-292: Wheel consumption looks good.Arch-conditional install from pyarrow-builder is sound. Ensure wheels directory is empty on non‑Power to avoid accidental glob matches (already handled).
|
@jiridanek: 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. |
5 tasks
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
Conflict resolution from
Description
How Has This Been Tested?
Self checklist (all need to be checked):
make test(gmakeon macOS) before asking for reviewDockerfile.konfluxfiles should be done inodh/notebooksand automatically synced torhds/notebooks. For Konflux-specific changes, modifyDockerfile.konfluxfiles directly inrhds/notebooksas these require special attention in the downstream repository and flow to the upcoming RHOAI release.Merge criteria:
Summary by CodeRabbit
New Features
Performance
Chores