-
Notifications
You must be signed in to change notification settings - Fork 105
RHOAIENG-10351: Split JupyterLab installation out of the user's venv, so that there's fewer dependencies that need to be aligned #728
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
PR needs rebase. 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. |
# Disable announcement plugin of jupyterlab | ||
RUN jupyter labextension disable "@jupyterlab/apputils-extension:announcements" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we're running this as root on main, that's a mistake
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
WalkthroughThe changes restructure Jupyter image builds by introducing a Poetry-based dependency management system with a new Changes
Sequence Diagram(s)sequenceDiagram
participant Dockerfile
participant VirtualEnv
participant Poetry
participant System
Dockerfile->>VirtualEnv: Create virtual environment at /opt/app-root/opt
Dockerfile->>VirtualEnv: Copy pyproject.toml & poetry.lock
Dockerfile->>Poetry: Install JupyterLab & dependencies via Poetry
Poetry->>VirtualEnv: Install packages
Dockerfile->>System: Remove project files, fix permissions
Dockerfile->>System: Create symlinks for Jupyter binaries
Dockerfile->>VirtualEnv: Install ipykernel and kernel spec
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~15–20 minutes Suggested labels
Suggested reviewers
Poem
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 7
♻️ Duplicate comments (1)
jupyter/datascience/ubi9-python-3.11/Dockerfile (1)
24-25
: Repeated root escalation contradicts earlier hardening goalsPrior reviews (see comment “we're running this as root on main, that's a mistake”) flagged the unnecessary
USER root
switches. Combine all link creations in the earlier root block of the minimal base image and keep this stage running as UID 1001.
🧹 Nitpick comments (2)
jupyter/datascience/ubi9-python-3.11/Dockerfile (2)
71-71
:rm
without-f
breaks when directory is already emptyIf the upstream minimal image prunes runtime JSONs, this
rm
exits with code 1 and aborts the build. Add-f
or|| true
.
47-58
: Layer installs many client libs as root – consider slimmingInstalling
git-lfs
,mssql-tools18
, and fullmongodb
client hugely increases the image size (>350 MB). Evaluate moving them to a dedicated “datascience-extras” variant or recommend users install via pip when needed.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (3)
jupyter/datascience/ubi9-python-3.11/Pipfile.lock
is excluded by!**/*.lock
jupyter/minimal/ubi9-python-3.11/Pipfile.lock
is excluded by!**/*.lock
jupyter/minimal/ubi9-python-3.11/poetry.lock
is excluded by!**/*.lock
📒 Files selected for processing (5)
jupyter/datascience/ubi9-python-3.11/Dockerfile
(2 hunks)jupyter/datascience/ubi9-python-3.11/Pipfile
(1 hunks)jupyter/minimal/ubi9-python-3.11/Dockerfile
(2 hunks)jupyter/minimal/ubi9-python-3.11/Pipfile
(1 hunks)jupyter/minimal/ubi9-python-3.11/pyproject.toml
(1 hunks)
🧰 Additional context used
🧠 Learnings (33)
📓 Common learnings
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/datascience/ubi9-python-3.12/Pipfile:33-34
Timestamp: 2025-07-08T19:26:17.140Z
Learning: jiridanek requested GitHub issue creation for jupyter-client dependency pinning inconsistency during PR #1333 review, specifically asking to note the implications of breaking changes in 9.x versions. Issue #1343 was created with comprehensive problem description covering inconsistent pinning style across all Python 3.12 runtime images, detailed breaking changes analysis (kernel protocol, session management, connection security, API changes, async/await modifications), reproducibility and security impact assessment, multiple solution options with code examples, phased acceptance criteria, implementation guidance, testing approach, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/utils/pip.conf:3-4
Timestamp: 2025-07-08T19:21:11.512Z
Learning: jiridanek requested GitHub issue creation for PYTHONPATH configuration investigation in runtime images during PR #1333 review. Issue #1339 was created with comprehensive problem description covering pip.conf target directory configuration, missing PYTHONPATH exports, potential runtime import failures, multiple investigation areas (PYTHONPATH auditing, pip configuration consistency, runtime testing), solution options with implementation guidance, 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#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.131Z
Learning: jiridanek requested GitHub issue creation for RStudio py311 Tekton push pipelines during PR #1379 review. Issue #1384 was successfully created covering two RStudio variants (CPU and CUDA) found in manifests/base/params-latest.env, with comprehensive problem description, implementation requirements following the same pattern as other workbench pipelines, 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#1333
File: runtimes/pytorch/ubi9-python-3.12/Dockerfile.cuda:17-25
Timestamp: 2025-07-09T08:07:30.628Z
Learning: jiridanek requested GitHub issue creation for oc client installation permission problem in PyTorch CUDA runtime Dockerfile during PR #1333 review. Issue #1356 was created with comprehensive problem description covering USER 1001 permission conflicts with root-owned /opt/app-root/bin directory, detailed impact analysis of build failures and non-executable binaries, current problematic code snippet, complete solution with user switching approach, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1379
File: .tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-push.yaml:14-17
Timestamp: 2025-07-11T11:15:47.424Z
Learning: jiridanek requested GitHub issue creation for CEL filter problem in datascience workbench Tekton pipelines during PR #1379 review. Issue #1383 was successfully created with comprehensive problem description covering both Python 3.11 and 3.12 pipelines incorrectly watching jupyter/minimal directories instead of jupyter/datascience directories, detailed impact analysis of pipeline execution failures, complete solution with before/after code examples, thorough acceptance criteria for path updates and pipeline triggering verification, implementation notes about repository structure alignment, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
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#1333
File: runtimes/rocm-pytorch/ubi9-python-3.12/de-vendor-torch.sh:9-12
Timestamp: 2025-07-08T19:28:15.791Z
Learning: jiridanek requested GitHub issue creation for runtime detection improvement of Python site-packages paths during PR #1333 review. Issue #1344 was created with comprehensive problem description covering hard-coded path fragility across UBI9 distributions, extensive affected files analysis including 4 de-vendor scripts, 30+ Dockerfiles with chmod operations, and 12+ pip.conf configurations, runtime detection solution using sysconfig module, implementation areas breakdown, benefits analysis, 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#1333
File: runtimes/rocm-pytorch/ubi9-python-3.12/utils/bootstrapper.py:1-769
Timestamp: 2025-07-08T19:35:49.482Z
Learning: jiridanek requested GitHub issue creation for bootstrapper code duplication problem in runtimes/rocm-pytorch/ubi9-python-3.12/utils/bootstrapper.py during PR #1333 review. After an initial failed attempt, issue #1349 was successfully created with comprehensive problem description covering maintenance overhead and consistency risks from duplicate implementations across 5 Python 3.12 runtime environments, four solution options (symlinks, import-based, template-based, direct shared import) with pros/cons analysis, clear acceptance criteria for consolidation and maintainability, step-by-step implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.131Z
Learning: jiridanek requested GitHub issue creation for adding RStudio py311 Tekton push pipelines during PR #1379 review, referencing existing registry entries in manifests/base/params-latest.env but missing corresponding .tekton pipeline files. A comprehensive issue was created with detailed problem description, implementation requirements following the same pattern as other workbench pipelines, 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#1269
File: codeserver/ubi9-python-3.12/requirements.txt:435-444
Timestamp: 2025-07-03T13:59:55.040Z
Learning: jiridanek requested GitHub issue creation for numpy/scipy compatibility investigation in PR #1269, specifically for cases where theoretical version conflicts don't manifest as actual build failures. Issue #1297 was created with comprehensive investigation framework, acceptance criteria, runtime testing approach, and proper context linking, demonstrating the pattern of creating investigation-type issues for apparent but non-blocking technical concerns that require deeper understanding.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1519
File: jupyter/pytorch+llmcompressor/ubi9-python-3.11/runtime-images/llmcompressor-pytorch-ubi9-py311.json:2-9
Timestamp: 2025-07-30T08:42:19.393Z
Learning: The new architecture for runtime images in opendatahub-io/notebooks uses a dynamic system instead of static JSON files: (1) Runtime images are defined as ImageStreams in manifests/base/ with `opendatahub.io/runtime-image: "true"` label and JSON metadata in `opendatahub.io/runtime-image-metadata` annotation, (2) odh-notebook-controller dynamically creates JSONs in configmaps by listing ImageStreams on cluster, (3) Elyra-enabled workbenches get these JSONs mounted and setup-elyra.sh moves them from `/opt/app-root/pipeline-runtimes/..data/*.json` to `/opt/app-root/share/jupyter/metadata/runtime-images/`. Static JSON files in `*/runtime-images/` directories are no longer used.
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#1218
File: jupyter/datascience/ubi9-python-3.11/Pipfile:34-36
Timestamp: 2025-06-28T14:13:27.890Z
Learning: In the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pattern: core `jupyterlab` package uses exact pinning (==) across all notebook images to ensure UI consistency, while JupyterLab extensions and all server components (jupyter-server, jupyter-server-proxy, jupyter-server-terminals) use compatible release (~=) pinning to allow automatic security updates and bug fixes while maintaining API compatibility.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-03T07:03:45.020Z
Learning: The Python 3.11 infrastructure for ROCm TensorFlow images in opendatahub-io/notebooks is already properly configured in the Makefile with both BASE_DIRS entries for Pipfile lock renewals and all-images targets for CI builds, requiring only commenting out the corresponding Python 3.12 entries when downgrading due to wheel availability issues.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1519
File: jupyter/pytorch+llmcompressor/ubi9-python-3.11/runtime-images/llmcompressor-pytorch-ubi9-py311.json:2-9
Timestamp: 2025-07-29T16:00:31.637Z
Learning: jiridanek indicated that the current practice for runtime-images JSON files in opendatahub-io/notebooks has changed significantly from the SHA256 digest pinning pattern, and that rebasing PR #1519 would reveal the new practice which is "something completely different" from the existing pattern.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1519
File: jupyter/pytorch+llmcompressor/ubi9-python-3.11/runtime-images/llmcompressor-pytorch-ubi9-py311.json:2-9
Timestamp: 2025-07-29T15:56:20.036Z
Learning: Current practice for runtime-images JSON files in opendatahub-io/notebooks: All runtime image configurations use SHA256 digest pinning (format: `@sha256:<digest>`) instead of mutable tags for immutability, use `quay.io/opendatahub/workbench-images` registry, include `schema_name: "runtime-image"` field, and follow consistent structure as seen in existing files like datascience-ubi9-py311.json, pytorch-ubi9-py311.json, etc.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu:4-4
Timestamp: 2025-07-04T05:49:10.314Z
Learning: jiridanek directs base image pinning security concerns to existing comprehensive issue #1242 "Improve Docker FROM image versioning by avoiding :latest tags" rather than addressing them in individual PRs, continuing the established pattern of systematic security and quality tracking in opendatahub-io/notebooks.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:34-35
Timestamp: 2025-07-04T10:41:13.061Z
Learning: In the opendatahub-io/notebooks repository, when adapting NVIDIA CUDA Dockerfiles, the project intentionally maintains consistency with upstream NVIDIA patterns even when it might involve potential risks like empty variable expansions in package installation commands. This is considered acceptable because the containers only run on RHEL 9 with known yum/dnf behavior, and upstream consistency is prioritized over defensive coding practices.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/nginx/root/usr/share/container-scripts/nginx/common.sh:1-3
Timestamp: 2025-07-03T12:07:19.365Z
Learning: jiridanek consistently requests GitHub issue creation for technical improvements identified during code reviews in opendatahub-io/notebooks, ensuring systematic tracking of code quality enhancements like shell script portability issues with comprehensive descriptions, solution options, and acceptance criteria.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/utils/process.sh:17-19
Timestamp: 2025-07-03T14:00:00.909Z
Learning: jiridanek efficiently identifies when CodeRabbit review suggestions are already covered by existing comprehensive issues, demonstrating excellent issue management and avoiding duplicate tracking of the same improvements across multiple locations.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1151
File: jupyter/tensorflow/ubi9-python-3.12/test/test_notebook.ipynb:31-34
Timestamp: 2025-07-01T07:03:05.385Z
Learning: jiridanek demonstrates excellent pattern recognition for identifying duplicated code issues across the opendatahub-io/notebooks repository. When spotting a potential problem in test notebooks, he correctly assesses that such patterns are likely replicated across multiple similar files rather than being isolated incidents, leading to more effective systematic solutions.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Dockerfile.rocm:56-66
Timestamp: 2025-07-02T18:19:49.397Z
Learning: jiridanek consistently creates comprehensive follow-up GitHub issues for security concerns raised during PR reviews in opendatahub-io/notebooks, ensuring systematic tracking and resolution of supply-chain security improvements like GPG signature verification for package repositories.
📚 Learning: jiridanek requested github issue creation for improving fragile sed-based jupyter kernel display_nam...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu:135-136
Timestamp: 2025-07-04T05:52:49.464Z
Learning: jiridanek requested GitHub issue creation for improving fragile sed-based Jupyter kernel display_name modification in jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu during PR #1306 review. Issue #1321 was created with comprehensive problem description covering JSON corruption risks, greedy regex patterns, maintenance burden, and proposed Python-based JSON parsing solution with detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
📚 Learning: in the opendatahub-io/notebooks repository, when adapting nvidia cuda dockerfiles, the project inten...
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:34-35
Timestamp: 2025-07-04T10:41:13.061Z
Learning: In the opendatahub-io/notebooks repository, when adapting NVIDIA CUDA Dockerfiles, the project intentionally maintains consistency with upstream NVIDIA patterns even when it might involve potential risks like empty variable expansions in package installation commands. This is considered acceptable because the containers only run on RHEL 9 with known yum/dnf behavior, and upstream consistency is prioritized over defensive coding practices.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
📚 Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatah...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatahub-io/notebooks. They run `pipenv lock` inside UBI9 containers with specific platform arguments (`--platform=linux/amd64 --python-version 3.12`) to avoid host OS dependency conflicts when generating Pipfile.lock files.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: the python 3.11 infrastructure for rocm tensorflow images in opendatahub-io/notebooks is already pro...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-03T07:03:45.020Z
Learning: The Python 3.11 infrastructure for ROCm TensorFlow images in opendatahub-io/notebooks is already properly configured in the Makefile with both BASE_DIRS entries for Pipfile lock renewals and all-images targets for CI builds, requiring only commenting out the corresponding Python 3.12 entries when downgrading due to wheel availability issues.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/minimal/ubi9-python-3.11/Pipfile
📚 Learning: jiridanek directs base image pinning security concerns to existing comprehensive issue #1242 "improv...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu:4-4
Timestamp: 2025-07-04T05:49:10.314Z
Learning: jiridanek directs base image pinning security concerns to existing comprehensive issue #1242 "Improve Docker FROM image versioning by avoiding :latest tags" rather than addressing them in individual PRs, continuing the established pattern of systematic security and quality tracking in opendatahub-io/notebooks.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
📚 Learning: in the opendatahub-io/notebooks repository, the test runner's python version (configured in github a...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1247
File: .github/workflows/build-notebooks-TEMPLATE.yaml:50-53
Timestamp: 2025-07-01T14:36:52.852Z
Learning: In the opendatahub-io/notebooks repository, the test runner's Python version (configured in GitHub Actions UV setup) intentionally doesn't need to match the Python version of the container images being tested. jiridanek's team uses Python 3.12 for running tests while images may use different Python versions (like 3.11), and this approach works fine since the test code is separate from the application code running inside the containers.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
📚 Learning: jiridanek requested github issue creation for runtime detection improvement of python site-packages ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-pytorch/ubi9-python-3.12/de-vendor-torch.sh:9-12
Timestamp: 2025-07-08T19:28:15.791Z
Learning: jiridanek requested GitHub issue creation for runtime detection improvement of Python site-packages paths during PR #1333 review. Issue #1344 was created with comprehensive problem description covering hard-coded path fragility across UBI9 distributions, extensive affected files analysis including 4 de-vendor scripts, 30+ Dockerfiles with chmod operations, and 12+ pip.conf configurations, runtime detection solution using sysconfig module, implementation areas breakdown, benefits analysis, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
📚 Learning: jiridanek requested github issue creation for oc client installation permission problem in pytorch c...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/pytorch/ubi9-python-3.12/Dockerfile.cuda:17-25
Timestamp: 2025-07-09T08:07:30.628Z
Learning: jiridanek requested GitHub issue creation for oc client installation permission problem in PyTorch CUDA runtime Dockerfile during PR #1333 review. Issue #1356 was created with comprehensive problem description covering USER 1001 permission conflicts with root-owned /opt/app-root/bin directory, detailed impact analysis of build failures and non-executable binaries, current problematic code snippet, complete solution with user switching approach, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
📚 Learning: jiridanek requested github issue creation for pythonpath configuration investigation in runtime imag...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/utils/pip.conf:3-4
Timestamp: 2025-07-08T19:21:11.512Z
Learning: jiridanek requested GitHub issue creation for PYTHONPATH configuration investigation in runtime images during PR #1333 review. Issue #1339 was created with comprehensive problem description covering pip.conf target directory configuration, missing PYTHONPATH exports, potential runtime import failures, multiple investigation areas (PYTHONPATH auditing, pip configuration consistency, runtime testing), solution options with implementation guidance, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
📚 Learning: jiridanek requested github issue creation for misleading cuda prefix in trustyai image tags during p...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/kustomize/base/kustomization.yaml:8-12
Timestamp: 2025-07-08T19:09:48.746Z
Learning: jiridanek requested GitHub issue creation for misleading CUDA prefix in TrustyAI image tags during PR #1306 review, affecting both Python 3.11 and 3.12 versions. Issue #1338 was created with comprehensive problem description covering both affected images, repository pattern analysis comparing correct vs incorrect naming conventions, clear solution with code examples, detailed acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
📚 Learning: in the opendatahub-io/notebooks repository, mounting emptydir volumes over /opt/app-root/src is inte...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1230
File: jupyter/pytorch/ubi9-python-3.12/kustomize/components/accelerator/pod-patch.yaml:11-22
Timestamp: 2025-06-30T14:35:34.805Z
Learning: In the opendatahub-io/notebooks repository, mounting emptyDir volumes over /opt/app-root/src is intentional behavior that matches production deployment patterns where odh-dashboard mounts empty PVCs at this location (the $HOME directory). This mounting is expected to hide base image content.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
📚 Learning: in the opendatahub-io/notebooks repository, mixing centos packages with ubi base images is bad pract...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1396
File: jupyter/tensorflow/ubi9-python-3.12/Dockerfile.cuda:192-195
Timestamp: 2025-07-18T19:01:39.811Z
Learning: In the opendatahub-io/notebooks repository, mixing CentOS packages with UBI base images is bad practice that removes supportability and creates "Frankenstein" images according to Red Hat guidance. However, using EPEL packages is acceptable, though it may require extra work with AIPCC for internal Red Hat builds. The official reference is at developers.redhat.com/articles/ubi-faq.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
📚 Learning: in opendatahub-io/notebooks, shell scripting robustness and efficiency issues in extension managemen...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-03T14:04:05.280Z
Learning: In opendatahub-io/notebooks, shell scripting robustness and efficiency issues in extension management loops (such as unquoted globs, word-splitting, and unnecessary repeated copies in run-code-server.sh) are systematically tracked and fixed by quoting variables, using `cp -a --`, and toggling `nullglob`, following the established pattern of operational correctness improvements.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
📚 Learning: runtime deployment tests in opendatahub-io/notebooks may show podsecurity warnings about allowprivil...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: Runtime deployment tests in opendatahub-io/notebooks may show PodSecurity warnings about allowPrivilegeEscalation, capabilities, runAsNonRoot, and seccompProfile settings. These warnings occur on OpenShift but not on GitHub Actions because GitHub Actions uses upstream Kubernetes without SecurityContextConstraints (SCC).
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
📚 Learning: in the opendatahub-io/notebooks repository, issue #1241 "security: add checksum verification for dow...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Dockerfile.rocm:34-37
Timestamp: 2025-07-02T18:19:23.024Z
Learning: In the opendatahub-io/notebooks repository, issue #1241 "Security: Add checksum verification for downloaded binaries in Python 3.12 images" covers the security concern about verifying downloaded binaries including the oc client. Red Hat does not provide signed RPM packages for the OpenShift CLI (oc) in UBI9 official repositories, making manual binary download with checksum verification the recommended approach.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
📚 Learning: issue #1212 in opendatahub-io/notebooks demonstrates that missing securitycontext configuration (all...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1230
File: jupyter/pytorch/ubi9-python-3.12/kustomize/base/statefulset.yaml:54-60
Timestamp: 2025-06-30T14:43:08.138Z
Learning: Issue #1212 in opendatahub-io/notebooks demonstrates that missing securityContext configuration (allowPrivilegeEscalation, runAsNonRoot, seccompProfile) causes runtime pods to fail reaching ready state and timeout after 300s on OpenShift due to PodSecurity policy violations.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
📚 Learning: in opendatahub-io/notebooks, python 3.12-based images (e.g., runtime-cuda-pytorch-ubi9-python-3.12) ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:54:28.202Z
Learning: In opendatahub-io/notebooks, Python 3.12-based images (e.g., runtime-cuda-pytorch-ubi9-python-3.12) may fail container runtime tests with "libcrypt.so.1 => not found" for MySQL SASL2 plugin libraries if `libxcrypt-compat` is missing. The solution is to install `libxcrypt-compat` in the Dockerfile.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
📚 Learning: the new architecture for runtime images in opendatahub-io/notebooks uses a dynamic system instead of...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1519
File: jupyter/pytorch+llmcompressor/ubi9-python-3.11/runtime-images/llmcompressor-pytorch-ubi9-py311.json:2-9
Timestamp: 2025-07-30T08:42:19.393Z
Learning: The new architecture for runtime images in opendatahub-io/notebooks uses a dynamic system instead of static JSON files: (1) Runtime images are defined as ImageStreams in manifests/base/ with `opendatahub.io/runtime-image: "true"` label and JSON metadata in `opendatahub.io/runtime-image-metadata` annotation, (2) odh-notebook-controller dynamically creates JSONs in configmaps by listing ImageStreams on cluster, (3) Elyra-enabled workbenches get these JSONs mounted and setup-elyra.sh moves them from `/opt/app-root/pipeline-runtimes/..data/*.json` to `/opt/app-root/share/jupyter/metadata/runtime-images/`. Static JSON files in `*/runtime-images/` directories are no longer used.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
📚 Learning: jiridanek requested github issue creation for subprocess.call to subprocess.run migration during pr ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/utils/bootstrapper.py:135-135
Timestamp: 2025-07-08T19:34:51.825Z
Learning: jiridanek requested GitHub issue creation for subprocess.call to subprocess.run migration during PR #1333 review. Investigation revealed broader scope affecting 12 bootstrapper.py files across both Python 3.11 and 3.12 runtime images plus CI test file. A comprehensive issue was created with detailed affected files analysis covering all runtime types (tensorflow, pytorch, rocm-tensorflow, rocm-pytorch, minimal, datascience), security and error handling concerns, multiple solution options, acceptance criteria, implementation guidance, and proper context linking, demonstrating the systematic code duplication pattern from Elyra project across the entire repository.
Applied to files:
jupyter/datascience/ubi9-python-3.11/Dockerfile
📚 Learning: in the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pat...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/datascience/ubi9-python-3.11/Pipfile:34-36
Timestamp: 2025-06-28T14:13:27.890Z
Learning: In the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pattern: core `jupyterlab` package uses exact pinning (==) across all notebook images to ensure UI consistency, while JupyterLab extensions and all server components (jupyter-server, jupyter-server-proxy, jupyter-server-terminals) use compatible release (~=) pinning to allow automatic security updates and bug fixes while maintaining API compatibility.
Applied to files:
jupyter/datascience/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: trustyai explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.tx...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
Applied to files:
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: jiridanek requested github issue creation for runtime detection improvement of python site-packages ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-pytorch/ubi9-python-3.12/de-vendor-torch.sh:9-12
Timestamp: 2025-07-08T19:28:15.791Z
Learning: jiridanek requested GitHub issue creation for runtime detection improvement of Python site-packages paths during PR #1333 review. Issue #1340 was created with comprehensive problem description covering hard-coded path fragility across UBI9 distributions, affected files analysis including de-vendor scripts and pip.conf configurations, runtime detection solution using sysconfig module, implementation areas breakdown, benefits analysis, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/minimal/ubi9-python-3.11/pyproject.toml
📚 Learning: jiridanek requested verification of 2024.2 tag package versions against corresponding pipfiles durin...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-24T12:01:45.188Z
Learning: jiridanek requested verification of 2024.2 tag package versions against corresponding Pipfiles during PR #1496 review. The analysis revealed that 2024.2 tags contain intentionally frozen older versions (N-1 behavior) while the current PR correctly updates only the N (latest) tags to match Python 3.11 Pipfiles, demonstrating proper understanding of the repository's N-1 version freezing policy.
Applied to files:
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: jiridanek requested github issue creation for jupyter-client dependency pinning inconsistency during...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/datascience/ubi9-python-3.12/Pipfile:33-34
Timestamp: 2025-07-08T19:26:17.140Z
Learning: jiridanek requested GitHub issue creation for jupyter-client dependency pinning inconsistency during PR #1333 review, specifically asking to note the implications of breaking changes in 9.x versions. Issue #1343 was created with comprehensive problem description covering inconsistent pinning style across all Python 3.12 runtime images, detailed breaking changes analysis (kernel protocol, session management, connection security, API changes, async/await modifications), reproducibility and security impact assessment, multiple solution options with code examples, phased acceptance criteria, implementation guidance, testing approach, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: jiridanek requested github issue creation for python 3.12 version check bug in bootstrapper.py durin...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/pytorch/ubi9-python-3.12/utils/bootstrapper.py:619-626
Timestamp: 2025-07-08T19:33:14.340Z
Learning: jiridanek requested GitHub issue creation for Python 3.12 version check bug in bootstrapper.py during PR #1333 review. Issue #1348 was created with comprehensive problem description covering version check exclusion affecting all Python 3.12 runtime images, detailed impact analysis of bootstrapper execution failures, clear solution with code examples, affected files list including all 6 runtime bootstrapper copies, acceptance criteria for testing and verification, implementation notes about code duplication and upstream reporting, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/minimal/ubi9-python-3.11/pyproject.toml
📚 Learning: the canonical package name for the jupyter bokeh extension on pypi is `jupyter_bokeh` (with undersco...
Learnt from: devcoons
PR: opendatahub-io/notebooks#1494
File: jupyter/tensorflow/ubi9-python-3.11/Pipfile:40-40
Timestamp: 2025-07-23T22:32:21.847Z
Learning: The canonical package name for the Jupyter Bokeh extension on PyPI is `jupyter_bokeh` (with underscore), not `jupyter-bokeh` (with hyphen). PyPI accepts both forms when querying but the official canonical name returned by the API is `jupyter_bokeh`. This should be used in Pipfiles to ensure consistent dependency resolution across the opendatahub-io/notebooks repository.
Applied to files:
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: the jupyter-bokeh package was previously pinned to version 3.0.5 in the trustyai notebook image due ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
Applied to files:
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: odh-elyra uses universal wheels (py3-none-any) rather than platform-specific wheels, making it compa...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1325
File: jupyter/datascience/ubi9-python-3.11/Pipfile:32-32
Timestamp: 2025-07-07T14:54:57.907Z
Learning: odh-elyra uses universal wheels (py3-none-any) rather than platform-specific wheels, making it compatible with all supported Python versions through a single wheel file.
Applied to files:
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: the jupyter-bokeh pinning to 3.0.5 in trustyai notebook image was not due to trustyai code compatibi...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: The jupyter-bokeh pinning to 3.0.5 in TrustyAI notebook image was not due to TrustyAI code compatibility issues, but because the trustyai package itself explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency, causing pip dependency resolution conflicts when trying to upgrade to jupyter-bokeh 4.x.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: the tensorflow rocm python 3.12 compatibility issue in opendatahub-io/notebooks pr #1259 was caused ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-23T16:18:42.922Z
Learning: The TensorFlow ROCm Python 3.12 compatibility issue in opendatahub-io/notebooks PR #1259 was caused by using tensorflow-rocm==2.14.0.600 in Pipfile.lock which lacks Python 3.12 wheels, while the Pipfile specifies tensorflow_rocm=~=2.18.1. The solution requires updating Pipfile sources to include https://repo.radeon.com/rocm/manylinux/rocm-rel-6.4/ repository which contains tensorflow_rocm-2.18.1-cp312-cp312-manylinux_2_28_x86_64.whl and regenerating Pipfile.lock using the piplock-refresh GitHub Action.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
📚 Learning: trustyai's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with trustyai's visua...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: trustyai 0.6.1 (latest version as of june 2025) has a hard dependency constraint on jupyter-bokeh~=3...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI 0.6.1 (latest version as of June 2025) has a hard dependency constraint on jupyter-bokeh~=3.0.5, preventing upgrades to jupyter-bokeh 4.x in notebook images that include TrustyAI. This requires either waiting for TrustyAI to update their dependency or excluding TrustyAI from jupyter-bokeh upgrades.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/datascience/ubi9-python-3.11/Pipfile
🔇 Additional comments (2)
jupyter/minimal/ubi9-python-3.11/Dockerfile (1)
14-23
:PYTHON_VERSION
is assumed but never set in this stage
python${PYTHON_VERSION}
and the path/opt/.../python${PYTHON_VERSION}
fail if the env var is unset in the base image (several runtimes forgot to export it in the past). EitherARG PYTHON_VERSION=3.11
before use or replace withpython3.11
to avoid brittle builds.jupyter/datascience/ubi9-python-3.11/Dockerfile (1)
14-23
: Virtual-env presumed to existThe stage uses
/opt/app-root/opt
but never creates it. If the chosenBASE_IMAGE
stops providing that venv the build will silently install into the global site-packages and permission fixes below will miss their target. Add an explicitRUN python${PYTHON_VERSION} -m venv /opt/app-root/opt
before activating.
# Jupyter kernel | ||
# c.f. https://docs.jupyter.org/en/latest/install/kernels.html#how-do-i-install-python-2-and-python-3 | ||
ipykernel = "~=6.29.5" | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Same jupyter-client issue as minimal image
Add an 8.x upper-bound to avoid unvetted protocol changes:
ipykernel = "~=6.29.5"
+jupyter-client = ">=8,<9"
📝 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.
# Jupyter kernel | |
# c.f. https://docs.jupyter.org/en/latest/install/kernels.html#how-do-i-install-python-2-and-python-3 | |
ipykernel = "~=6.29.5" | |
# Jupyter kernel | |
# c.f. https://docs.jupyter.org/en/latest/install/kernels.html#how-do-i-install-python-2-and-python-3 | |
ipykernel = "~=6.29.5" | |
jupyter-client = ">=8,<9" |
🤖 Prompt for AI Agents
In jupyter/datascience/ubi9-python-3.11/Pipfile around lines 29 to 32, the
ipykernel dependency lacks an upper bound on jupyter-client, which can lead to
issues due to unvetted protocol changes. Modify the ipykernel dependency to
include an upper bound of 8.x for jupyter-client by specifying a compatible
version range that prevents upgrading beyond 8.x.
RUN ln -s /opt/app-root/opt/bin/jupyter /usr/local/bin/jupyter | ||
RUN ln -s /opt/app-root/opt/bin/jupyter-lab /usr/local/bin/jupyter-lab | ||
RUN ln -s /opt/app-root/opt/bin/jupyter-labextension /usr/local/bin/jupyter-labextension |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Symlinking jupyter-labextension
is obsolete with JupyterLab 4
Since JL 4 the standalone jupyter-labextension
entry-point was removed; only jupyter labextension …
remains. The symlink will point to a non-existent file and fail the layer. Drop the line or fall back to ln -s /usr/local/bin/jupyter /usr/local/bin/jupyter-labextension
.
🤖 Prompt for AI Agents
In jupyter/minimal/ubi9-python-3.11/Dockerfile at lines 25 to 27, the symlink
creation for jupyter-labextension is obsolete because JupyterLab 4 removed the
standalone jupyter-labextension entry point. Remove the line creating the
symlink for jupyter-labextension or replace it with a symlink pointing to
/usr/local/bin/jupyter to avoid referencing a non-existent file and causing
build failures.
# Replace Notebook's launcher, "(ipykernel)" with Python's version 3.x.y | ||
RUN sed -i -e "s/Python.*/$(python --version | cut -d '.' -f-2)\",/" /opt/app-root/share/jupyter/kernels/python3/kernel.json | ||
RUN python${PYTHON_VERSION} -m ipykernel install --prefix /opt/app-root/opt --name python3 --display-name "$(python -c 'import sys; major, minor, *_ = sys.version_info; print(f"Python {major}.{minor}")')" | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Kernel spec installed with system interpreter, not the venv
python${PYTHON_VERSION} -m ipykernel
runs the system interpreter, yet writes the spec into the venv prefix. If ipykernel got installed only inside /opt/app-root/opt
, this will crash. Safer:
-RUN python${PYTHON_VERSION} -m ipykernel install --prefix /opt/app-root/opt ...
+RUN /opt/app-root/opt/bin/python -m ipykernel install --prefix /opt/app-root/opt ...
📝 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.
# Replace Notebook's launcher, "(ipykernel)" with Python's version 3.x.y | |
RUN sed -i -e "s/Python.*/$(python --version | cut -d '.' -f-2)\",/" /opt/app-root/share/jupyter/kernels/python3/kernel.json | |
RUN python${PYTHON_VERSION} -m ipykernel install --prefix /opt/app-root/opt --name python3 --display-name "$(python -c 'import sys; major, minor, *_ = sys.version_info; print(f"Python {major}.{minor}")')" | |
# Replace Notebook's launcher, "(ipykernel)" with Python's version 3.x.y | |
RUN /opt/app-root/opt/bin/python -m ipykernel install --prefix /opt/app-root/opt --name python3 --display-name "$(python -c 'import sys; major, minor, *_ = sys.version_info; print(f"Python {major}.{minor}")')" |
🤖 Prompt for AI Agents
In jupyter/minimal/ubi9-python-3.11/Dockerfile around lines 46 to 48, the
command uses the system Python interpreter to install the ipykernel spec into
the virtual environment prefix, which can cause crashes if ipykernel is only
installed in the venv. Modify the command to run ipykernel using the Python
interpreter from the virtual environment itself, ensuring the kernel spec is
installed with the correct interpreter context.
# Jupyter kernel | ||
# c.f. https://docs.jupyter.org/en/latest/install/kernels.html#how-do-i-install-python-2-and-python-3 | ||
ipykernel = "~=6.29.5" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Verification agent
❓ Verification inconclusive
Missing jupyter-client
guard opens the 9.x breaking-change can
ipykernel>=6.29
will happily pull jupyter-client>=9
whose protocol changes broke several images (see issue #1343). Add an explicit upper bound to stay on the 8.x line until the codebase is audited.
ipykernel = "~=6.29.5"
+jupyter-client = ">=8,<9"
Guard jupyter-client to <9 in the minimal Python 3.11 image
ipykernel 6.29+ will pull in jupyter-client 9.x, whose protocol changes break existing kernels (see issue #1343). Add an explicit upper bound to remain on the 8.x line until we’ve audited and adapted to the 9.x API.
• File: jupyter/minimal/ubi9-python-3.11/Pipfile (around lines 10–12)
ipykernel = "~=6.29.5"
+jupyter-client = ">=8,<9"
🤖 Prompt for AI Agents
In jupyter/minimal/ubi9-python-3.11/Pipfile around lines 10 to 12, the ipykernel
dependency currently allows jupyter-client version 9.x, which breaks existing
kernels due to protocol changes. To fix this, add an explicit upper bound to the
jupyter-client dependency to restrict it to versions below 9, ensuring
compatibility until the new API is audited and adapted.
# JupyterLab packages | ||
jupyterlab = "~=4.2.4" | ||
jupyter-bokeh = "~=4.0.5" | ||
jupyter-server = "~=2.14.2" | ||
jupyter-server-proxy = "~=4.3.0" | ||
jupyter-server-terminals = "~=0.5.3" | ||
jupyterlab-git = "~=0.50.1" | ||
jupyterlab-lsp = "~=5.1.0" | ||
jupyterlab-widgets = "~=3.0.13" | ||
jupyter-resource-usage = "~=1.1.0" | ||
nbdime = "~=4.0.1" | ||
nbgitpuller = "~=1.2.1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Verification agent
❓ Verification inconclusive
Pin style diverges from established JupyterLab policy
All other notebook images pin jupyterlab
exactly (==
) to guarantee UI parity, while server components get ~=
. Switching to ~=4.2.4
here silently opens the door to 4.3 / 4.4 mismatches between images.
In the same block the canonical PyPI name for Bokeh is jupyter_bokeh
, not jupyter-bokeh
, which occasionally breaks hash-based installs or vulnerability scanners that normalise names.
Consider:
-jupyterlab = "~=4.2.4"
-jupyter-bokeh = "~=4.0.5"
+jupyterlab = "==4.2.4"
+jupyter_bokeh = "~=4.0.5"
#!/bin/bash
set -e
echo "== Checking jupyterlab pinning style in Python 3.11 pyproject.toml files =="
rg -n 'jupyterlab\s*=' --glob "jupyter/*/ubi9-python-3.11/pyproject.toml"
echo
echo "== Checking jupyter[-_]bokeh naming in Python 3.11 pyproject.toml files =="
rg -n 'jupyter[-_]bokeh\s*=' --glob "jupyter/*/ubi9-python-3.11/pyproject.toml"
Align JupyterLab Pinning and Bokeh Package Name
Please update the pinning style and package name to match repository policy:
• In jupyter/minimal/ubi9-python-3.11/pyproject.toml (lines 12–23):
- Pin
jupyterlab
exactly (==4.2.4
) to guarantee UI parity. - Use the canonical PyPI name
jupyter_bokeh
(underscore) instead ofjupyter-bokeh
.
Suggested diff:
-jupyterlab = "~=4.2.4"
-jupyter-bokeh = "~=4.0.5"
+jupyterlab = "==4.2.4"
+jupyter_bokeh = "~=4.0.5"
🤖 Prompt for AI Agents
In jupyter/minimal/ubi9-python-3.11/pyproject.toml between lines 12 and 23,
change the version specifier for jupyterlab from a compatible version (~=4.2.4)
to an exact version (==4.2.4) to ensure UI consistency. Also, rename the package
jupyter-bokeh to jupyter_bokeh to use the canonical PyPI package name with an
underscore.
nbdime = "~=4.0.1" | ||
nbgitpuller = "~=1.2.1" | ||
# https://github.com/jupyterlab/jupyterlab/issues/509#issuecomment-234659696 | ||
pyyaml = "*" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unbounded pyyaml
version is a supply-chain foot-gun
pyyaml = "*"
means the image will pick up any future 7.x/8.x major that may change the C-loader ABI or drop deprecated APIs. Pin with a compatible range (e.g. ~=6.0
) to keep automatic CVE backports while avoiding untested majors.
🤖 Prompt for AI Agents
In jupyter/minimal/ubi9-python-3.11/pyproject.toml at line 25, the pyyaml
dependency is specified with an unbounded version "*", which risks pulling in
incompatible major versions that may break the build or runtime. Change the
version specifier to a compatible range such as "~=6.0" to ensure automatic
security updates within the 6.x series while avoiding untested major version
upgrades.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
♻️ Duplicate comments (6)
jupyter/minimal/ubi9-python-3.11/pyproject.toml (2)
13-15
: Alignjupyterlab
pinning & use canonicaljupyter_bokeh
nameThe repository convention is
jupyterlab ==<exact>
for UI parity and the canonical PyPI namejupyter_bokeh
. Please switch from the compatible-range pin and hyphenated name.-jupyterlab = "~=4.2.4" -jupyter-bokeh = "~=4.0.5" +jupyterlab = "==4.2.4" +jupyter_bokeh = "~=4.0.5"
25-25
: Boundpyyaml
to the 6.x line
pyyaml = "*"
may pull an untested 7.x/8.x major. Use a compatible range, e.g.:-pyyaml = "*" +pyyaml = "~=6.0"jupyter/minimal/ubi9-python-3.11/Dockerfile (2)
25-27
: Symlink to removedjupyter-labextension
entry-point will break the layerSince JupyterLab 4 the standalone
jupyter-labextension
script no longer exists.
Creating this symlink causes a build failure.-RUN ln -s /opt/app-root/opt/bin/jupyter-labextension /usr/local/bin/jupyter-labextension
Delete the line or point it at the main
jupyter
CLI if you need backward-compat.
46-48
: Kernel spec installed with system interpreter, not the venvRunning
python${PYTHON_VERSION} -m ipykernel …
invokes the system interpreter even though the spec is written into/opt/app-root/opt
. Use the venv’s interpreter to avoid mismatch:-RUN python${PYTHON_VERSION} -m ipykernel install --prefix /opt/app-root/opt ... +RUN /opt/app-root/opt/bin/python -m ipykernel install --prefix /opt/app-root/opt ...jupyter/minimal/ubi9-python-3.11/Pipfile (1)
10-13
: Guardjupyter-client
to < 9 to avoid protocol breakage
ipykernel >= 6.29
will happily upgradejupyter-client
to 9.x, whose protocol changes broke existing kernels (issue #1343). Add an upper bound:ipykernel = "~=6.29.5" +jupyter-client = ">=8,<9"
jupyter/datascience/ubi9-python-3.11/Pipfile (1)
29-31
: Add explicit<9
upper-bound forjupyter-client
Same rationale as the minimal image—avoid unintended upgrade to 9.x until audited.
ipykernel = "~=6.29.5" +jupyter-client = ">=8,<9"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (3)
jupyter/datascience/ubi9-python-3.11/Pipfile.lock
is excluded by!**/*.lock
jupyter/minimal/ubi9-python-3.11/Pipfile.lock
is excluded by!**/*.lock
jupyter/minimal/ubi9-python-3.11/poetry.lock
is excluded by!**/*.lock
📒 Files selected for processing (5)
jupyter/datascience/ubi9-python-3.11/Dockerfile
(2 hunks)jupyter/datascience/ubi9-python-3.11/Pipfile
(1 hunks)jupyter/minimal/ubi9-python-3.11/Dockerfile
(2 hunks)jupyter/minimal/ubi9-python-3.11/Pipfile
(1 hunks)jupyter/minimal/ubi9-python-3.11/pyproject.toml
(1 hunks)
🧰 Additional context used
🧠 Learnings (43)
📓 Common learnings
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/datascience/ubi9-python-3.12/Pipfile:33-34
Timestamp: 2025-07-08T19:26:17.140Z
Learning: jiridanek requested GitHub issue creation for jupyter-client dependency pinning inconsistency during PR #1333 review, specifically asking to note the implications of breaking changes in 9.x versions. Issue #1343 was created with comprehensive problem description covering inconsistent pinning style across all Python 3.12 runtime images, detailed breaking changes analysis (kernel protocol, session management, connection security, API changes, async/await modifications), reproducibility and security impact assessment, multiple solution options with code examples, phased acceptance criteria, implementation guidance, testing approach, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/pytorch/ubi9-python-3.12/Dockerfile.cuda:17-25
Timestamp: 2025-07-09T08:07:30.628Z
Learning: jiridanek requested GitHub issue creation for oc client installation permission problem in PyTorch CUDA runtime Dockerfile during PR #1333 review. Issue #1356 was created with comprehensive problem description covering USER 1001 permission conflicts with root-owned /opt/app-root/bin directory, detailed impact analysis of build failures and non-executable binaries, current problematic code snippet, complete solution with user switching approach, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.131Z
Learning: jiridanek requested GitHub issue creation for RStudio py311 Tekton push pipelines during PR #1379 review. Issue #1384 was successfully created covering two RStudio variants (CPU and CUDA) found in manifests/base/params-latest.env, with comprehensive problem description, implementation requirements following the same pattern as other workbench pipelines, 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#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/utils/pip.conf:3-4
Timestamp: 2025-07-08T19:21:11.512Z
Learning: jiridanek requested GitHub issue creation for PYTHONPATH configuration investigation in runtime images during PR #1333 review. Issue #1339 was created with comprehensive problem description covering pip.conf target directory configuration, missing PYTHONPATH exports, potential runtime import failures, multiple investigation areas (PYTHONPATH auditing, pip configuration consistency, runtime testing), solution options with implementation guidance, 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#1379
File: .tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-push.yaml:14-17
Timestamp: 2025-07-11T11:15:47.424Z
Learning: jiridanek requested GitHub issue creation for CEL filter problem in datascience workbench Tekton pipelines during PR #1379 review. Issue #1383 was successfully created with comprehensive problem description covering both Python 3.11 and 3.12 pipelines incorrectly watching jupyter/minimal directories instead of jupyter/datascience directories, detailed impact analysis of pipeline execution failures, complete solution with before/after code examples, thorough acceptance criteria for path updates and pipeline triggering verification, implementation notes about repository structure alignment, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
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#1333
File: runtimes/rocm-pytorch/ubi9-python-3.12/de-vendor-torch.sh:9-12
Timestamp: 2025-07-08T19:28:15.791Z
Learning: jiridanek requested GitHub issue creation for runtime detection improvement of Python site-packages paths during PR #1333 review. Issue #1344 was created with comprehensive problem description covering hard-coded path fragility across UBI9 distributions, extensive affected files analysis including 4 de-vendor scripts, 30+ Dockerfiles with chmod operations, and 12+ pip.conf configurations, runtime detection solution using sysconfig module, implementation areas breakdown, benefits analysis, 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#1333
File: runtimes/rocm-pytorch/ubi9-python-3.12/utils/bootstrapper.py:1-769
Timestamp: 2025-07-08T19:35:49.482Z
Learning: jiridanek requested GitHub issue creation for bootstrapper code duplication problem in runtimes/rocm-pytorch/ubi9-python-3.12/utils/bootstrapper.py during PR #1333 review. After an initial failed attempt, issue #1349 was successfully created with comprehensive problem description covering maintenance overhead and consistency risks from duplicate implementations across 5 Python 3.12 runtime environments, four solution options (symlinks, import-based, template-based, direct shared import) with pros/cons analysis, clear acceptance criteria for consolidation and maintainability, step-by-step implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.131Z
Learning: jiridanek requested GitHub issue creation for adding RStudio py311 Tekton push pipelines during PR #1379 review, referencing existing registry entries in manifests/base/params-latest.env but missing corresponding .tekton pipeline files. A comprehensive issue was created with detailed problem description, implementation requirements following the same pattern as other workbench pipelines, 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#1269
File: codeserver/ubi9-python-3.12/requirements.txt:435-444
Timestamp: 2025-07-03T13:59:55.040Z
Learning: jiridanek requested GitHub issue creation for numpy/scipy compatibility investigation in PR #1269, specifically for cases where theoretical version conflicts don't manifest as actual build failures. Issue #1297 was created with comprehensive investigation framework, acceptance criteria, runtime testing approach, and proper context linking, demonstrating the pattern of creating investigation-type issues for apparent but non-blocking technical concerns that require deeper understanding.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1519
File: jupyter/pytorch+llmcompressor/ubi9-python-3.11/runtime-images/llmcompressor-pytorch-ubi9-py311.json:2-9
Timestamp: 2025-07-30T08:42:19.393Z
Learning: The new architecture for runtime images in opendatahub-io/notebooks uses a dynamic system instead of static JSON files: (1) Runtime images are defined as ImageStreams in manifests/base/ with `opendatahub.io/runtime-image: "true"` label and JSON metadata in `opendatahub.io/runtime-image-metadata` annotation, (2) odh-notebook-controller dynamically creates JSONs in configmaps by listing ImageStreams on cluster, (3) Elyra-enabled workbenches get these JSONs mounted and setup-elyra.sh moves them from `/opt/app-root/pipeline-runtimes/..data/*.json` to `/opt/app-root/share/jupyter/metadata/runtime-images/`. Static JSON files in `*/runtime-images/` directories are no longer used.
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#1218
File: jupyter/datascience/ubi9-python-3.11/Pipfile:34-36
Timestamp: 2025-06-28T14:13:27.890Z
Learning: In the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pattern: core `jupyterlab` package uses exact pinning (==) across all notebook images to ensure UI consistency, while JupyterLab extensions and all server components (jupyter-server, jupyter-server-proxy, jupyter-server-terminals) use compatible release (~=) pinning to allow automatic security updates and bug fixes while maintaining API compatibility.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-03T07:03:45.020Z
Learning: The Python 3.11 infrastructure for ROCm TensorFlow images in opendatahub-io/notebooks is already properly configured in the Makefile with both BASE_DIRS entries for Pipfile lock renewals and all-images targets for CI builds, requiring only commenting out the corresponding Python 3.12 entries when downgrading due to wheel availability issues.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1519
File: jupyter/pytorch+llmcompressor/ubi9-python-3.11/runtime-images/llmcompressor-pytorch-ubi9-py311.json:2-9
Timestamp: 2025-07-29T16:00:31.637Z
Learning: jiridanek indicated that the current practice for runtime-images JSON files in opendatahub-io/notebooks has changed significantly from the SHA256 digest pinning pattern, and that rebasing PR #1519 would reveal the new practice which is "something completely different" from the existing pattern.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1519
File: jupyter/pytorch+llmcompressor/ubi9-python-3.11/runtime-images/llmcompressor-pytorch-ubi9-py311.json:2-9
Timestamp: 2025-07-29T15:56:20.036Z
Learning: Current practice for runtime-images JSON files in opendatahub-io/notebooks: All runtime image configurations use SHA256 digest pinning (format: `@sha256:<digest>`) instead of mutable tags for immutability, use `quay.io/opendatahub/workbench-images` registry, include `schema_name: "runtime-image"` field, and follow consistent structure as seen in existing files like datascience-ubi9-py311.json, pytorch-ubi9-py311.json, etc.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu:4-4
Timestamp: 2025-07-04T05:49:10.314Z
Learning: jiridanek directs base image pinning security concerns to existing comprehensive issue #1242 "Improve Docker FROM image versioning by avoiding :latest tags" rather than addressing them in individual PRs, continuing the established pattern of systematic security and quality tracking in opendatahub-io/notebooks.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:34-35
Timestamp: 2025-07-04T10:41:13.061Z
Learning: In the opendatahub-io/notebooks repository, when adapting NVIDIA CUDA Dockerfiles, the project intentionally maintains consistency with upstream NVIDIA patterns even when it might involve potential risks like empty variable expansions in package installation commands. This is considered acceptable because the containers only run on RHEL 9 with known yum/dnf behavior, and upstream consistency is prioritized over defensive coding practices.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/nginx/root/usr/share/container-scripts/nginx/common.sh:1-3
Timestamp: 2025-07-03T12:07:19.365Z
Learning: jiridanek consistently requests GitHub issue creation for technical improvements identified during code reviews in opendatahub-io/notebooks, ensuring systematic tracking of code quality enhancements like shell script portability issues with comprehensive descriptions, solution options, and acceptance criteria.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/utils/process.sh:17-19
Timestamp: 2025-07-03T14:00:00.909Z
Learning: jiridanek efficiently identifies when CodeRabbit review suggestions are already covered by existing comprehensive issues, demonstrating excellent issue management and avoiding duplicate tracking of the same improvements across multiple locations.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1151
File: jupyter/tensorflow/ubi9-python-3.12/test/test_notebook.ipynb:31-34
Timestamp: 2025-07-01T07:03:05.385Z
Learning: jiridanek demonstrates excellent pattern recognition for identifying duplicated code issues across the opendatahub-io/notebooks repository. When spotting a potential problem in test notebooks, he correctly assesses that such patterns are likely replicated across multiple similar files rather than being isolated incidents, leading to more effective systematic solutions.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Dockerfile.rocm:56-66
Timestamp: 2025-07-02T18:19:49.397Z
Learning: jiridanek consistently creates comprehensive follow-up GitHub issues for security concerns raised during PR reviews in opendatahub-io/notebooks, ensuring systematic tracking and resolution of supply-chain security improvements like GPG signature verification for package repositories.
📚 Learning: in the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pat...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/datascience/ubi9-python-3.11/Pipfile:34-36
Timestamp: 2025-06-28T14:13:27.890Z
Learning: In the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pattern: core `jupyterlab` package uses exact pinning (==) across all notebook images to ensure UI consistency, while JupyterLab extensions and all server components (jupyter-server, jupyter-server-proxy, jupyter-server-terminals) use compatible release (~=) pinning to allow automatic security updates and bug fixes while maintaining API compatibility.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: jiridanek requested github issue creation for jupyter-client dependency pinning inconsistency during...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/datascience/ubi9-python-3.12/Pipfile:33-34
Timestamp: 2025-07-08T19:26:17.140Z
Learning: jiridanek requested GitHub issue creation for jupyter-client dependency pinning inconsistency during PR #1333 review, specifically asking to note the implications of breaking changes in 9.x versions. Issue #1343 was created with comprehensive problem description covering inconsistent pinning style across all Python 3.12 runtime images, detailed breaking changes analysis (kernel protocol, session management, connection security, API changes, async/await modifications), reproducibility and security impact assessment, multiple solution options with code examples, phased acceptance criteria, implementation guidance, testing approach, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: jiridanek requested verification of 2024.2 tag package versions against corresponding pipfiles durin...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-24T12:01:45.188Z
Learning: jiridanek requested verification of 2024.2 tag package versions against corresponding Pipfiles during PR #1496 review. The analysis revealed that 2024.2 tags contain intentionally frozen older versions (N-1 behavior) while the current PR correctly updates only the N (latest) tags to match Python 3.11 Pipfiles, demonstrating proper understanding of the repository's N-1 version freezing policy.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: the jupyter-bokeh package was previously pinned to version 3.0.5 in the trustyai notebook image due ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: jiridanek requested github issue creation for cel filter problem in datascience workbench tekton pip...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1379
File: .tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-push.yaml:14-17
Timestamp: 2025-07-11T11:15:47.424Z
Learning: jiridanek requested GitHub issue creation for CEL filter problem in datascience workbench Tekton pipelines during PR #1379 review. Issue #1383 was successfully created with comprehensive problem description covering both Python 3.11 and 3.12 pipelines incorrectly watching jupyter/minimal directories instead of jupyter/datascience directories, detailed impact analysis of pipeline execution failures, complete solution with before/after code examples, thorough acceptance criteria for path updates and pipeline triggering verification, implementation notes about repository structure alignment, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
📚 Learning: jiridanek requested github issue creation for runtime detection improvement of python site-packages ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-pytorch/ubi9-python-3.12/de-vendor-torch.sh:9-12
Timestamp: 2025-07-08T19:28:15.791Z
Learning: jiridanek requested GitHub issue creation for runtime detection improvement of Python site-packages paths during PR #1333 review. Issue #1344 was created with comprehensive problem description covering hard-coded path fragility across UBI9 distributions, extensive affected files analysis including 4 de-vendor scripts, 30+ Dockerfiles with chmod operations, and 12+ pip.conf configurations, runtime detection solution using sysconfig module, implementation areas breakdown, benefits analysis, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
📚 Learning: the canonical package name for the jupyter bokeh extension on pypi is `jupyter_bokeh` (with undersco...
Learnt from: devcoons
PR: opendatahub-io/notebooks#1494
File: jupyter/tensorflow/ubi9-python-3.11/Pipfile:40-40
Timestamp: 2025-07-23T22:32:21.847Z
Learning: The canonical package name for the Jupyter Bokeh extension on PyPI is `jupyter_bokeh` (with underscore), not `jupyter-bokeh` (with hyphen). PyPI accepts both forms when querying but the official canonical name returned by the API is `jupyter_bokeh`. This should be used in Pipfiles to ensure consistent dependency resolution across the opendatahub-io/notebooks repository.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatah...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatahub-io/notebooks. They run `pipenv lock` inside UBI9 containers with specific platform arguments (`--platform=linux/amd64 --python-version 3.12`) to avoid host OS dependency conflicts when generating Pipfile.lock files.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: jiridanek requested github issue creation for improving fragile sed-based jupyter kernel display_nam...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu:135-136
Timestamp: 2025-07-04T05:52:49.464Z
Learning: jiridanek requested GitHub issue creation for improving fragile sed-based Jupyter kernel display_name modification in jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu during PR #1306 review. Issue #1321 was created with comprehensive problem description covering JSON corruption risks, greedy regex patterns, maintenance burden, and proposed Python-based JSON parsing solution with detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: jiridanek requested github issue creation for pythonpath configuration investigation in runtime imag...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/utils/pip.conf:3-4
Timestamp: 2025-07-08T19:21:11.512Z
Learning: jiridanek requested GitHub issue creation for PYTHONPATH configuration investigation in runtime images during PR #1333 review. Issue #1339 was created with comprehensive problem description covering pip.conf target directory configuration, missing PYTHONPATH exports, potential runtime import failures, multiple investigation areas (PYTHONPATH auditing, pip configuration consistency, runtime testing), solution options with implementation guidance, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
📚 Learning: jiridanek requested github issue creation for misleading cuda prefix in trustyai image tags during p...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/kustomize/base/kustomization.yaml:8-12
Timestamp: 2025-07-08T19:09:48.746Z
Learning: jiridanek requested GitHub issue creation for misleading CUDA prefix in TrustyAI image tags during PR #1306 review, affecting both Python 3.11 and 3.12 versions. Issue #1338 was created with comprehensive problem description covering both affected images, repository pattern analysis comparing correct vs incorrect naming conventions, clear solution with code examples, detailed acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: jiridanek directs security concerns raised during pr reviews to existing comprehensive security issu...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1258
File: codeserver/ubi9-python-3.11/Dockerfile.cpu:55-56
Timestamp: 2025-07-03T08:22:25.348Z
Learning: jiridanek directs security concerns raised during PR reviews to existing comprehensive security issues rather than addressing them in individual PRs. Issue #1241 "Security: Add checksum verification for downloaded binaries in Python 3.12 images" serves as the central tracking issue for all binary download security concerns across the opendatahub-io/notebooks repository.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
📚 Learning: in the opendatahub-io/notebooks repository, issue #1241 "security: add checksum verification for dow...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Dockerfile.rocm:34-37
Timestamp: 2025-07-02T18:19:23.024Z
Learning: In the opendatahub-io/notebooks repository, issue #1241 "Security: Add checksum verification for downloaded binaries in Python 3.12 images" covers the security concern about verifying downloaded binaries including the oc client. Red Hat does not provide signed RPM packages for the OpenShift CLI (oc) in UBI9 official repositories, making manual binary download with checksum verification the recommended approach.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/minimal/ubi9-python-3.11/Dockerfile
📚 Learning: jiridanek requested github issue creation for misleading cuda prefix in trustyai image tags during p...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/kustomize/base/kustomization.yaml:8-12
Timestamp: 2025-07-08T19:09:48.746Z
Learning: jiridanek requested GitHub issue creation for misleading CUDA prefix in TrustyAI image tags during PR #1306 review. Issue was created with comprehensive problem description covering both Python 3.11 and 3.12 versions, repository pattern analysis showing correct vs incorrect naming, clear solution with code examples, detailed acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
📚 Learning: trustyai 0.6.1 (latest version as of june 2025) has a hard dependency constraint on jupyter-bokeh~=3...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI 0.6.1 (latest version as of June 2025) has a hard dependency constraint on jupyter-bokeh~=3.0.5, preventing upgrades to jupyter-bokeh 4.x in notebook images that include TrustyAI. This requires either waiting for TrustyAI to update their dependency or excluding TrustyAI from jupyter-bokeh upgrades.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: jiridanek directs base image pinning security concerns to existing comprehensive issue #1242 "improv...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu:4-4
Timestamp: 2025-07-04T05:49:10.314Z
Learning: jiridanek directs base image pinning security concerns to existing comprehensive issue #1242 "Improve Docker FROM image versioning by avoiding :latest tags" rather than addressing them in individual PRs, continuing the established pattern of systematic security and quality tracking in opendatahub-io/notebooks.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
📚 Learning: trustyai explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.tx...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: the jupyter-bokeh pinning to 3.0.5 in trustyai notebook image was not due to trustyai code compatibi...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: The jupyter-bokeh pinning to 3.0.5 in TrustyAI notebook image was not due to TrustyAI code compatibility issues, but because the trustyai package itself explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency, causing pip dependency resolution conflicts when trying to upgrade to jupyter-bokeh 4.x.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Pipfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: in the opendatahub-io/notebooks repository, when adapting nvidia cuda dockerfiles, the project inten...
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:34-35
Timestamp: 2025-07-04T10:41:13.061Z
Learning: In the opendatahub-io/notebooks repository, when adapting NVIDIA CUDA Dockerfiles, the project intentionally maintains consistency with upstream NVIDIA patterns even when it might involve potential risks like empty variable expansions in package installation commands. This is considered acceptable because the containers only run on RHEL 9 with known yum/dnf behavior, and upstream consistency is prioritized over defensive coding practices.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
📚 Learning: the python 3.11 infrastructure for rocm tensorflow images in opendatahub-io/notebooks is already pro...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-03T07:03:45.020Z
Learning: The Python 3.11 infrastructure for ROCm TensorFlow images in opendatahub-io/notebooks is already properly configured in the Makefile with both BASE_DIRS entries for Pipfile lock renewals and all-images targets for CI builds, requiring only commenting out the corresponding Python 3.12 entries when downgrading due to wheel availability issues.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
📚 Learning: jiridanek requested github issue creation for oc client installation permission problem in pytorch c...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/pytorch/ubi9-python-3.12/Dockerfile.cuda:17-25
Timestamp: 2025-07-09T08:07:30.628Z
Learning: jiridanek requested GitHub issue creation for oc client installation permission problem in PyTorch CUDA runtime Dockerfile during PR #1333 review. Issue #1356 was created with comprehensive problem description covering USER 1001 permission conflicts with root-owned /opt/app-root/bin directory, detailed impact analysis of build failures and non-executable binaries, current problematic code snippet, complete solution with user switching approach, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
📚 Learning: in the opendatahub-io/notebooks repository, the test runner's python version (configured in github a...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1247
File: .github/workflows/build-notebooks-TEMPLATE.yaml:50-53
Timestamp: 2025-07-01T14:36:52.852Z
Learning: In the opendatahub-io/notebooks repository, the test runner's Python version (configured in GitHub Actions UV setup) intentionally doesn't need to match the Python version of the container images being tested. jiridanek's team uses Python 3.12 for running tests while images may use different Python versions (like 3.11), and this approach works fine since the test code is separate from the application code running inside the containers.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
📚 Learning: in opendatahub-io/notebooks, shell scripting robustness and efficiency issues in extension managemen...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-03T14:04:05.280Z
Learning: In opendatahub-io/notebooks, shell scripting robustness and efficiency issues in extension management loops (such as unquoted globs, word-splitting, and unnecessary repeated copies in run-code-server.sh) are systematically tracked and fixed by quoting variables, using `cp -a --`, and toggling `nullglob`, following the established pattern of operational correctness improvements.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
📚 Learning: jiridanek requested github issue creation for shell script variable quoting security concern in code...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/run-nginx.sh:18-23
Timestamp: 2025-07-03T16:17:23.065Z
Learning: jiridanek requested GitHub issue creation for shell script variable quoting security concern in codeserver/ubi9-python-3.12/run-nginx.sh during PR #1269 review. The issue covers unquoted variables NB_PREFIX, NOTEBOOK_ARGS, and BASE_URL that pose security risks including command injection, word-splitting vulnerabilities, and globbing issues. A comprehensive issue was created with detailed problem description, security concerns, solution with code examples, acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
📚 Learning: jiridanek requested github issue creation for runtime detection improvement of python site-packages ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-pytorch/ubi9-python-3.12/de-vendor-torch.sh:9-12
Timestamp: 2025-07-08T19:28:15.791Z
Learning: jiridanek requested GitHub issue creation for runtime detection improvement of Python site-packages paths during PR #1333 review. Issue #1340 was created with comprehensive problem description covering hard-coded path fragility across UBI9 distributions, affected files analysis including de-vendor scripts and pip.conf configurations, runtime detection solution using sysconfig module, implementation areas breakdown, benefits analysis, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
📚 Learning: jiridanek requests github issue creation for shell script quality improvements identified during pr ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/run-code-server.sh:17-17
Timestamp: 2025-07-03T12:26:24.084Z
Learning: jiridanek requests GitHub issue creation for shell script quality improvements identified during PR #1269 review, specifically for unquoted command substitution in codeserver/ubi9-python-3.12/run-code-server.sh. Issue #1283 was created with comprehensive problem descriptions, acceptance criteria, implementation guidance, and proper context linking.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
📚 Learning: jiridanek requested github issue creation for shell script quality improvements in codeserver/ubi9-p...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/nginx/root/usr/share/container-scripts/nginx/common.sh:4-11
Timestamp: 2025-07-03T16:04:22.695Z
Learning: jiridanek requested GitHub issue creation for shell script quality improvements in codeserver/ubi9-python-3.12/nginx/root/usr/share/container-scripts/nginx/common.sh during PR #1269 review. Issue #1307 was created with comprehensive problem description covering variable scoping issues, POSIX compliance concerns, multiple solution options, acceptance criteria, implementation guidance with code examples, testing approaches, and proper context linking, continuing the established pattern of systematic code quality improvements.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
📚 Learning: jiridanek requested github issue creation for shell script error handling improvements in codeserver...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/nginx/root/opt/app-root/etc/generate_container_user:4-9
Timestamp: 2025-07-03T16:05:35.448Z
Learning: jiridanek requested GitHub issue creation for shell script error handling improvements in codeserver/ubi9-python-3.12/nginx/root/opt/app-root/etc/generate_container_user during PR #1269 review. A comprehensive issue was created covering silent failures, unquoted variable expansions, missing template validation, and strict mode implementation with detailed problem descriptions, phased acceptance criteria, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
📚 Learning: in the opendatahub-io/notebooks repository, mounting emptydir volumes over /opt/app-root/src is inte...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1230
File: jupyter/pytorch/ubi9-python-3.12/kustomize/components/accelerator/pod-patch.yaml:11-22
Timestamp: 2025-06-30T14:35:34.805Z
Learning: In the opendatahub-io/notebooks repository, mounting emptyDir volumes over /opt/app-root/src is intentional behavior that matches production deployment patterns where odh-dashboard mounts empty PVCs at this location (the $HOME directory). This mounting is expected to hide base image content.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
📚 Learning: in the opendatahub-io/notebooks repository, mixing centos packages with ubi base images is bad pract...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1396
File: jupyter/tensorflow/ubi9-python-3.12/Dockerfile.cuda:192-195
Timestamp: 2025-07-18T19:01:39.811Z
Learning: In the opendatahub-io/notebooks repository, mixing CentOS packages with UBI base images is bad practice that removes supportability and creates "Frankenstein" images according to Red Hat guidance. However, using EPEL packages is acceptable, though it may require extra work with AIPCC for internal Red Hat builds. The official reference is at developers.redhat.com/articles/ubi-faq.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
jupyter/minimal/ubi9-python-3.11/pyproject.toml
📚 Learning: runtime deployment tests in opendatahub-io/notebooks may show podsecurity warnings about allowprivil...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: Runtime deployment tests in opendatahub-io/notebooks may show PodSecurity warnings about allowPrivilegeEscalation, capabilities, runAsNonRoot, and seccompProfile settings. These warnings occur on OpenShift but not on GitHub Actions because GitHub Actions uses upstream Kubernetes without SecurityContextConstraints (SCC).
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
📚 Learning: issue #1212 in opendatahub-io/notebooks demonstrates that missing securitycontext configuration (all...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1230
File: jupyter/pytorch/ubi9-python-3.12/kustomize/base/statefulset.yaml:54-60
Timestamp: 2025-06-30T14:43:08.138Z
Learning: Issue #1212 in opendatahub-io/notebooks demonstrates that missing securityContext configuration (allowPrivilegeEscalation, runAsNonRoot, seccompProfile) causes runtime pods to fail reaching ready state and timeout after 300s on OpenShift due to PodSecurity policy violations.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
📚 Learning: in opendatahub-io/notebooks, python 3.12-based images (e.g., runtime-cuda-pytorch-ubi9-python-3.12) ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:54:28.202Z
Learning: In opendatahub-io/notebooks, Python 3.12-based images (e.g., runtime-cuda-pytorch-ubi9-python-3.12) may fail container runtime tests with "libcrypt.so.1 => not found" for MySQL SASL2 plugin libraries if `libxcrypt-compat` is missing. The solution is to install `libxcrypt-compat` in the Dockerfile.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
📚 Learning: the new architecture for runtime images in opendatahub-io/notebooks uses a dynamic system instead of...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1519
File: jupyter/pytorch+llmcompressor/ubi9-python-3.11/runtime-images/llmcompressor-pytorch-ubi9-py311.json:2-9
Timestamp: 2025-07-30T08:42:19.393Z
Learning: The new architecture for runtime images in opendatahub-io/notebooks uses a dynamic system instead of static JSON files: (1) Runtime images are defined as ImageStreams in manifests/base/ with `opendatahub.io/runtime-image: "true"` label and JSON metadata in `opendatahub.io/runtime-image-metadata` annotation, (2) odh-notebook-controller dynamically creates JSONs in configmaps by listing ImageStreams on cluster, (3) Elyra-enabled workbenches get these JSONs mounted and setup-elyra.sh moves them from `/opt/app-root/pipeline-runtimes/..data/*.json` to `/opt/app-root/share/jupyter/metadata/runtime-images/`. Static JSON files in `*/runtime-images/` directories are no longer used.
Applied to files:
jupyter/minimal/ubi9-python-3.11/Dockerfile
jupyter/datascience/ubi9-python-3.11/Dockerfile
📚 Learning: jiridanek indicated that the current practice for runtime-images json files in opendatahub-io/notebo...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1519
File: jupyter/pytorch+llmcompressor/ubi9-python-3.11/runtime-images/llmcompressor-pytorch-ubi9-py311.json:2-9
Timestamp: 2025-07-29T16:00:31.637Z
Learning: jiridanek indicated that the current practice for runtime-images JSON files in opendatahub-io/notebooks has changed significantly from the SHA256 digest pinning pattern, and that rebasing PR #1519 would reveal the new practice which is "something completely different" from the existing pattern.
Applied to files:
jupyter/datascience/ubi9-python-3.11/Dockerfile
📚 Learning: jiridanek requested github issue creation for python 3.12 version check bug in bootstrapper.py durin...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/pytorch/ubi9-python-3.12/utils/bootstrapper.py:619-626
Timestamp: 2025-07-08T19:33:14.340Z
Learning: jiridanek requested GitHub issue creation for Python 3.12 version check bug in bootstrapper.py during PR #1333 review. Issue #1348 was created with comprehensive problem description covering version check exclusion affecting all Python 3.12 runtime images, detailed impact analysis of bootstrapper execution failures, clear solution with code examples, affected files list including all 6 runtime bootstrapper copies, acceptance criteria for testing and verification, implementation notes about code duplication and upstream reporting, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/minimal/ubi9-python-3.11/pyproject.toml
📚 Learning: jiridanek requested github issue creation for bootstrapper code duplication problem in runtimes/rocm...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-pytorch/ubi9-python-3.12/utils/bootstrapper.py:1-769
Timestamp: 2025-07-08T19:35:49.482Z
Learning: jiridanek requested GitHub issue creation for bootstrapper code duplication problem in runtimes/rocm-pytorch/ubi9-python-3.12/utils/bootstrapper.py during PR #1333 review. After an initial failed attempt, issue #1349 was successfully created with comprehensive problem description covering maintenance overhead and consistency risks from duplicate implementations across 5 Python 3.12 runtime environments, four solution options (symlinks, import-based, template-based, direct shared import) with pros/cons analysis, clear acceptance criteria for consolidation and maintainability, step-by-step implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/minimal/ubi9-python-3.11/pyproject.toml
📚 Learning: jiridanek requested github issue creation for subprocess.call to subprocess.run migration during pr ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/utils/bootstrapper.py:135-135
Timestamp: 2025-07-08T19:34:51.825Z
Learning: jiridanek requested GitHub issue creation for subprocess.call to subprocess.run migration during PR #1333 review. Investigation revealed broader scope affecting 12 bootstrapper.py files across both Python 3.11 and 3.12 runtime images plus CI test file. A comprehensive issue was created with detailed affected files analysis covering all runtime types (tensorflow, pytorch, rocm-tensorflow, rocm-pytorch, minimal, datascience), security and error handling concerns, multiple solution options, acceptance criteria, implementation guidance, and proper context linking, demonstrating the systematic code duplication pattern from Elyra project across the entire repository.
Applied to files:
jupyter/minimal/ubi9-python-3.11/pyproject.toml
📚 Learning: trustyai's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with trustyai's visua...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
Applied to files:
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: jiridanek identified that arm64 wheels for h5py 3.14.0 are available on pypi but being ignored due t...
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/minimal/ubi9-python-3.11/pyproject.toml
📚 Learning: odh-elyra uses universal wheels (py3-none-any) rather than platform-specific wheels, making it compa...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1325
File: jupyter/datascience/ubi9-python-3.11/Pipfile:32-32
Timestamp: 2025-07-07T14:54:57.907Z
Learning: odh-elyra uses universal wheels (py3-none-any) rather than platform-specific wheels, making it compatible with all supported Python versions through a single wheel file.
Applied to files:
jupyter/minimal/ubi9-python-3.11/pyproject.toml
jupyter/datascience/ubi9-python-3.11/Pipfile
📚 Learning: jiridanek corrected coderabbit's false positive about urllib3/requests version incompatibility in pr...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/minimal/ubi9-python-3.12/Pipfile:23-27
Timestamp: 2025-07-09T08:12:05.822Z
Learning: jiridanek corrected CodeRabbit's false positive about urllib3/requests version incompatibility in PR #1333 review. Investigation revealed that requests 2.32.3 actually requires `urllib3<3,>=1.21.1` (not `urllib3<2` as incorrectly stated), making urllib3 2.5.0 perfectly compatible. This demonstrates the importance of verifying technical assessments against actual build results and PyPI metadata before creating issues.
Applied to files:
jupyter/datascience/ubi9-python-3.11/Pipfile
🔇 Additional comments (1)
jupyter/datascience/ubi9-python-3.11/Dockerfile (1)
14-22
: Ensure the venv actually exists before pip-installing ElyraThis image assumes
/opt/app-root/opt
was created by the base image.
If the base switches, thepip install
will target the system site-packages and the VIRTUAL_ENV variable will be misleading.Please verify the base still contains the venv or create it here:
python${PYTHON_VERSION} -m venv /opt/app-root/opt
# Remove default Elyra runtime-images \ | ||
rm /opt/app-root/share/jupyter/metadata/runtime-images/*.json && \ | ||
rm /opt/app-root/opt/share/jupyter/metadata/runtime-images/*.json && \ | ||
# Fix permissions to support pip in Openshift environments \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rm *.json
fails the build when the glob is empty
rm /opt/app-root/opt/share/jupyter/metadata/runtime-images/*.json
exits with status 1 if no files match, aborting the RUN
layer. Make the command tolerant:
-rm /opt/app-root/opt/share/jupyter/metadata/runtime-images/*.json && \
+rm -f /opt/app-root/opt/share/jupyter/metadata/runtime-images/*.json || true && \
🤖 Prompt for AI Agents
In jupyter/datascience/ubi9-python-3.11/Dockerfile around lines 70 to 72, the rm
command fails if no JSON files exist, causing the build to abort. Modify the rm
command to avoid failure when no files match by adding the -f flag or using a
shell pattern that does not error on empty matches, ensuring the build continues
smoothly even if no files are present.
@@ -11,6 +11,19 @@ LABEL name="odh-notebook-jupyter-datascience-ubi9-python-3.11" \ | |||
io.openshift.build.source-location="https://github.com/opendatahub-io/notebooks/tree/main/jupyter/datascience/ubi9-python-3.11" \ | |||
io.openshift.build.image="quay.io/opendatahub/workbench-images:jupyter-datascience-ubi9-python-3.11" | |||
|
|||
WORKDIR /opt/app-root/opt |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this is the largest question right now; where to locate the other venv
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/opt/app-root/opt
is poor choice
@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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
interesting; looks like in some ways the idea of the whole PR goes against the uv single toml for everything goal we are pursuing elsewhere; have to reconcile the two efforts somehow
Description
jupyter/minimal
andjupyter/datascience
only, this way everything relevant is covered (elyra is included) while the amount of work is not large/opt/app-root/opt
, but when we implement this for real we should choose something more meaningful, maybe /opt/app-root/jupyter or /opt/jupyter?Pipfiles
and create a separate file to track it; I am choosing to do it in poetry, because we will migrate to poetry eventually; also, it allows me to keep everything in the same directory and it's clear that Pipfile applies to/opt/app-root/
venv and poetry applies to/opt/app-root/opt/
pyproject.toml
for the jupyterlab dependencies onlyHow Has This Been Tested?
are the images built from my pr in github actions https://github.com/jiridanek/notebooks/actions/runs/11180367092
when I run them,
and open jupyterlab in browser, I see
We are using the intended data science venv
This shows that the kernel runs in the data science venv as well. Jupyter runs in /opt/app-root/opt env. The
jupyter
in the datascience venv is a small wrapper that is installed when installing the kernel, it is by no means full jupyter (jupyter-lab).In any case, it seems to me sufficiently proven that what the RHOAIENG-10351 wants to achieve is achievable.
Merge criteria:
/hold
This is for review only, not for merging.
Summary by CodeRabbit
New Features
Refactor
Chores