RHOAIENG-18582: Post ODH Elyra release (v4.3.0) #2555
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Skipping CI for Draft Pull Request. |
WalkthroughThe PR updates odh-elyra to 4.3.x across images and manifests, modifies Elyra setup shell script behavior and env vars, and removes bootstrapper.py modules from multiple runtime images. One pylock includes broader package URL/hash churn. No new modules are added. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro 📒 Files selected for processing (8)
✅ Files skipped from review due to trivial changes (2)
🚧 Files skipped from review as they are similar to previous changes (1)
🧰 Additional context used🧠 Learnings (11)📓 Common learnings📚 Learning: 2025-09-04T16:34:03.232ZApplied to files:
📚 Learning: 2025-09-04T16:21:47.890ZApplied to files:
📚 Learning: 2025-08-08T14:48:51.662ZApplied to files:
📚 Learning: 2025-06-16T11:06:33.139ZApplied to files:
📚 Learning: 2025-09-04T16:23:06.395ZApplied to files:
📚 Learning: 2025-09-12T23:14:23.293ZApplied to files:
📚 Learning: 2025-08-08T14:57:20.636ZApplied to files:
📚 Learning: 2025-06-13T08:34:01.300ZApplied to files:
📚 Learning: 2025-09-18T10:46:07.688ZApplied to files:
📚 Learning: 2025-09-12T09:51:55.421ZApplied to files:
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (46)
🔇 Additional comments (5)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
bot
added
the
review-requested
atheo89
reviewed
Oct 7, 2025
| # Copy Elyra dependencies for air-gapped enviroment | ||
| COPY ${DATASCIENCE_SOURCE_CODE}/utils ./utils/ | ||
| # Download Elyra boostrapper.py | ||
| RUN curl -fL https://raw.githubusercontent.com/opendatahub-io/elyra/refs/heads/main/elyra/kfp/bootstrapper.py \ |
There was a problem hiding this comment.
Are we sure that this will work in disconnected envs?
There was a problem hiding this comment.
Hello @atheo89 I thought that it would work because this would be done during the image build time. The idea is now that Notebook images don't need a custom bootstrapper.py we could download it from Elyra and use the new system property we introduced: ELYRA_INSTALL_PACKAGES to prevent Elyra from trying to download packages - this new flag should do that
There was a problem hiding this comment.
Can we curl that file from a fixed tag (associated with the Elyra version in the image) instead of main?
EDIT: nvm, I saw the other comment below.
jiridanek
reviewed
Oct 8, 2025
| # Copy Elyra dependencies for air-gapped enviroment | ||
| COPY ${TENSORFLOW_SOURCE_CODE}/utils ./utils/ | ||
| # Download Elyra boostrapper.py | ||
| RUN curl -fL https://raw.githubusercontent.com/opendatahub-io/elyra/refs/tags/v4.3.0/elyra/kfp/bootstrapper.py \ |
There was a problem hiding this comment.
isn't this bootstrapper installed together with the odh-elyra package? Can't we grab it from python's site-packages? And if it is not installed, can't we install it that way?
There was a problem hiding this comment.
that's a great suggestion, it should be with the elyra package, it would be better to copy it from there - I will check and update the Dockerfile accordingly
There was a problem hiding this comment.
@jiridanek I found the local bootstrapper.py and copy it to utils on script setup-elyra.sh - would it be the best place to do it?
Thanks!
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (23)
jupyter/datascience/ubi9-python-3.12/pylock.toml(1 hunks)jupyter/datascience/ubi9-python-3.12/pyproject.toml(1 hunks)jupyter/datascience/ubi9-python-3.12/setup-elyra.sh(2 hunks)jupyter/pytorch+llmcompressor/ubi9-python-3.12/pylock.toml(1 hunks)jupyter/pytorch+llmcompressor/ubi9-python-3.12/pyproject.toml(1 hunks)jupyter/pytorch/ubi9-python-3.12/pylock.toml(1 hunks)jupyter/pytorch/ubi9-python-3.12/pyproject.toml(1 hunks)jupyter/rocm/pytorch/ubi9-python-3.12/pylock.toml(1 hunks)jupyter/rocm/pytorch/ubi9-python-3.12/pyproject.toml(1 hunks)jupyter/rocm/tensorflow/ubi9-python-3.12/pylock.toml(1 hunks)jupyter/rocm/tensorflow/ubi9-python-3.12/pyproject.toml(1 hunks)jupyter/tensorflow/ubi9-python-3.12/pylock.toml(1 hunks)jupyter/tensorflow/ubi9-python-3.12/pyproject.toml(1 hunks)jupyter/trustyai/ubi9-python-3.12/pylock.toml(1 hunks)jupyter/trustyai/ubi9-python-3.12/pyproject.toml(1 hunks)runtimes/datascience/ubi9-python-3.12/utils/bootstrapper.py(0 hunks)runtimes/minimal/ubi9-python-3.12/Dockerfile.cpu(1 hunks)runtimes/minimal/ubi9-python-3.12/utils/bootstrapper.py(0 hunks)runtimes/pytorch+llmcompressor/ubi9-python-3.12/utils/bootstrapper.py(0 hunks)runtimes/pytorch/ubi9-python-3.12/utils/bootstrapper.py(0 hunks)runtimes/rocm-pytorch/ubi9-python-3.12/utils/bootstrapper.py(0 hunks)runtimes/rocm-tensorflow/ubi9-python-3.12/utils/bootstrapper.py(0 hunks)runtimes/tensorflow/ubi9-python-3.12/utils/bootstrapper.py(0 hunks)
💤 Files with no reviewable changes (7)
- runtimes/rocm-tensorflow/ubi9-python-3.12/utils/bootstrapper.py
- runtimes/tensorflow/ubi9-python-3.12/utils/bootstrapper.py
- runtimes/pytorch+llmcompressor/ubi9-python-3.12/utils/bootstrapper.py
- runtimes/minimal/ubi9-python-3.12/utils/bootstrapper.py
- runtimes/datascience/ubi9-python-3.12/utils/bootstrapper.py
- runtimes/rocm-pytorch/ubi9-python-3.12/utils/bootstrapper.py
- runtimes/pytorch/ubi9-python-3.12/utils/bootstrapper.py
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1875
File: runtimes/pytorch/ubi9-python-3.12/pylock.toml:0-0
Timestamp: 2025-09-12T23:14:23.293Z
Learning: Issue #3325 in elyra-ai/elyra repository documents the urllib3 2.x compatibility blocker affecting jupyter/* images in opendatahub-io/notebooks. The dependency chain odh-elyra==4.2.3 → appengine-python-standard==1.1.10 → urllib3>=1.26.2,<2 prevents upgrading from urllib3=1.26.20 to 2.5.0 in images that include elyra, explaining why only codeserver/* and runtimes/* images achieved the 2.5.0 upgrade in PR #1875.
📚 Learning: 2025-09-12T23:14:23.293Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1875
File: runtimes/pytorch/ubi9-python-3.12/pylock.toml:0-0
Timestamp: 2025-09-12T23:14:23.293Z
Learning: Issue #3325 in elyra-ai/elyra repository documents the urllib3 2.x compatibility blocker affecting jupyter/* images in opendatahub-io/notebooks. The dependency chain odh-elyra==4.2.3 → appengine-python-standard==1.1.10 → urllib3>=1.26.2,<2 prevents upgrading from urllib3=1.26.20 to 2.5.0 in images that include elyra, explaining why only codeserver/* and runtimes/* images achieved the 2.5.0 upgrade in PR #1875.
Applied to files:
jupyter/trustyai/ubi9-python-3.12/pyproject.tomljupyter/trustyai/ubi9-python-3.12/pylock.tomljupyter/tensorflow/ubi9-python-3.12/pylock.tomljupyter/datascience/ubi9-python-3.12/pylock.tomljupyter/pytorch+llmcompressor/ubi9-python-3.12/pylock.tomljupyter/tensorflow/ubi9-python-3.12/pyproject.tomljupyter/datascience/ubi9-python-3.12/pyproject.tomljupyter/pytorch/ubi9-python-3.12/pyproject.tomljupyter/pytorch+llmcompressor/ubi9-python-3.12/pyproject.toml
📚 Learning: 2025-07-23T16:18:42.922Z
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/rocm/tensorflow/ubi9-python-3.12/pylock.toml
📚 Learning: 2025-08-29T12:20:28.311Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1875
File: runtimes/pytorch+llmcompressor/ubi9-python-3.12/Pipfile:70-70
Timestamp: 2025-08-29T12:20:28.311Z
Learning: jiridanek requested GitHub issue creation for urllib3 2.x compatibility blocked by appengine-python-standard dependency during PR #1875 review. Issue #3325 was created on elyra-ai/elyra repository explaining the dependency conflict chain (odh-elyra==4.2.3 → appengine-python-standard==1.1.10 → urllib3>=1.26.2,<2) that blocks updating urllib3 to 2.5.0 for CVE security fixes across notebook runtime environments.
Applied to files:
jupyter/tensorflow/ubi9-python-3.12/pyproject.tomljupyter/datascience/ubi9-python-3.12/pyproject.toml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (14)
- GitHub Check: Red Hat Konflux / odh-workbench-jupyter-pytorch-llmcompressor-cuda-py312-ubi9-on-pull-request
- GitHub Check: Red Hat Konflux / odh-workbench-jupyter-tensorflow-cuda-py312-ubi9-on-pull-request
- GitHub Check: Red Hat Konflux / odh-pipeline-runtime-pytorch-llmcompressor-cuda-py312-ubi9-on-pull-request
- GitHub Check: Red Hat Konflux / odh-workbench-jupyter-tensorflow-rocm-py312-ubi9-on-pull-request
- GitHub Check: Red Hat Konflux / odh-pipeline-runtime-pytorch-cuda-py312-ubi9-on-pull-request
- GitHub Check: Red Hat Konflux / odh-pipeline-runtime-tensorflow-cuda-py312-ubi9-on-pull-request
- GitHub Check: Red Hat Konflux / odh-workbench-jupyter-datascience-cpu-py312-ubi9-on-pull-request
- GitHub Check: Red Hat Konflux / odh-workbench-jupyter-trustyai-cpu-py312-ubi9-on-pull-request
- GitHub Check: Red Hat Konflux / odh-pipeline-runtime-pytorch-rocm-py312-ubi9-on-pull-request
- GitHub Check: Red Hat Konflux / odh-pipeline-runtime-tensorflow-rocm-py312-ubi9-on-pull-request
- GitHub Check: Red Hat Konflux / odh-workbench-jupyter-pytorch-rocm-py312-ubi9-on-pull-request
- GitHub Check: Red Hat Konflux / odh-workbench-jupyter-pytorch-cuda-py312-ubi9-on-pull-request
- GitHub Check: Red Hat Konflux / odh-pipeline-runtime-minimal-cpu-py312-ubi9-on-pull-request
- GitHub Check: Generate job matrix
🔇 Additional comments (6)
jupyter/pytorch/ubi9-python-3.12/pylock.toml (1)
2595-2599: Confirmed odh-elyra 4.3.1 artifacts on PyPI
sdist and wheel are live with matching SHA256 hashes; safe to merge.jupyter/rocm/tensorflow/ubi9-python-3.12/pylock.toml (1)
2511-2513: Confirm Elyra target version.This lockfile now pins
odh-elyrato 4.3.1, while the PR description frames the update as 4.3.0. Please double-check that 4.3.1 is the intended release (and already available for the build pipeline) before merging.jupyter/rocm/pytorch/ubi9-python-3.12/pylock.toml (1)
2459-2461: Lockfile entry looks consistent with 4.3.1.Version, URLs, timestamps, and hashes follow the established pattern for odh-elyra updates. 👍
jupyter/datascience/ubi9-python-3.12/pyproject.toml (1)
30-30: Dependency bump matches Elyra 4.3.x rollout.Thanks for updating the datascience image to pin
odh-elyra==4.3.1; this keeps it aligned with the new bootstrapper flow introduced elsewhere in the PR. No further action from my side.jupyter/pytorch+llmcompressor/ubi9-python-3.12/pyproject.toml (1)
46-46: Good to see odh-elyra unified at 4.3.1.The pytorch+llmcompressor image now tracks the same Elyra release as the rest of the stack, which will simplify maintenance once 4.3.x ships. Looks solid.
jupyter/pytorch+llmcompressor/ubi9-python-3.12/pylock.toml (1)
2706-2708: Confirm odh-elyra bump target, lock consistency, and urllib3 compatibility
Lock pins 4.3.1 but PR title says 4.3.0—confirm intended version, ensure all pylock.toml files use 4.3.1, and verify that appengine-python-standard no longer enforces urllib3<2.
Comment on lines
77
to
78
| RUN curl -fL https://raw.githubusercontent.com/opendatahub-io/elyra/refs/tags/v4.3.0/elyra/kfp/bootstrapper.py \ | ||
| -o ./utils/bootstrapper.py |
There was a problem hiding this comment.
Align bootstrapper version with Elyra bump and avoid network-dependent builds.
We now pull bootstrapper.py at build time from Elyra tag v4.3.0, but the rest of this PR upgrades ODH Elyra to 4.3.1. Shipping a 4.3.0 bootstrapper alongside 4.3.1 bits is a mismatch that can regress the fixes we’re picking up. In addition, downloading from GitHub during the build defeats disconnected/air-gapped builds—the very scenario the new ELYRA_INSTALL_PACKAGES=false knob is supposed to support. Please vendor the correct 4.3.1 bootstrapper (or fetch it from a pre-staged artifact inside the image) so the Docker build stays reproducible and works without external network access.
🤖 Prompt for AI Agents
In runtimes/minimal/ubi9-python-3.12/Dockerfile.cpu around lines 77-78, the
Dockerfile downloads bootstrapper.py from Elyra tag v4.3.0 at build time which
mismatches the repo bump to v4.3.1 and prevents air-gapped/disconnected builds;
replace the curl step with a reproducible, network-free approach by vendoring
the v4.3.1 bootstrapper into the build context (or copying it from a pre-staged
artifact inside the image/build context), update the Dockerfile to ADD/COPY that
local file into ./utils/bootstrapper.py instead of curling, and ensure the
vendored file version matches Elyra v4.3.1 (optionally add a checksum or comment
noting the source and tag).
There was a problem hiding this comment.
what if we do
cp /opt/app-root/lib/python3.12/site-packages/elyra/kfp/bootstrapper.py ...
There was a problem hiding this comment.
@jiridanek, that's an excellent solution! 🎯
Copying bootstrapper.py from the installed Elyra package would indeed solve both issues:
- ✅ Version alignment: Automatically uses the correct 4.3.1 version
- ✅ Air-gapped builds: No network dependency during build
However, there's an ordering consideration in the Dockerfile. Currently:
- Line 75:
COPY ${MINIMAL_SOURCE_CODE}/utils ./utils/ - Line 77-78:
curlbootstrapper.py (problematic) - Line 80:
uv pip install(this installs odh-elyra and creates site-packages)
To implement your approach, the copy would need to happen after the uv pip install step, since that's when the Elyra package gets installed to site-packages. Something like:
# Copy Elyra dependencies for air-gapped environment
COPY ${MINIMAL_SOURCE_CODE}/utils ./utils/
RUN echo "Installing softwares and packages" && \
uv pip install --strict --no-deps --no-cache ... && \
# Copy bootstrapper from installed Elyra package
cp /opt/app-root/lib/python3.12/site-packages/elyra/kfp/bootstrapper.py ./utils/bootstrapper.py && \
chmod -R g+w /opt/app-root/lib/python3.12/site-packages && \
fix-permissions /opt/app-root -PThis approach is cleaner, more maintainable, and naturally stays in sync with the Elyra version specified in pylock.toml. 👍
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check the current state of the Dockerfile
cat runtimes/minimal/ubi9-python-3.12/Dockerfile.cpu | grep -A 15 "Copy Elyra dependencies"
Length of output: 775
🏁 Script executed:
#!/bin/bash
# Look for any bootstrapper.py references in the file
grep -n "bootstrapper" runtimes/minimal/ubi9-python-3.12/Dockerfile.cpu
Length of output: 0
🏁 Script executed:
#!/bin/bash
# Check the entire RUN command that installs packages to see if cp was added
sed -n '/^RUN echo "Installing softwares and packages"/,/fix-permissions/p' runtimes/minimal/ubi9-python-3.12/Dockerfile.cpu
Length of output: 652
🏁 Script executed:
#!/bin/bash
# Check if bootstrapper.py exists in the minimal utils directory
ls -la runtimes/minimal/ubi9-python-3.12/utils/
Length of output: 236
🏁 Script executed:
#!/bin/bash
# Check if bootstrapper.py was deleted or is present
fd -t f "bootstrapper.py" runtimes/minimal/ubi9-python-3.12/
Length of output: 0
🏁 Script executed:
#!/bin/bash
# Check the git status of the minimal runtime to see what files changed
git diff --name-status origin/main...HEAD -- runtimes/minimal/ubi9-python-3.12/ | head -20
Length of output: 40
🏁 Script executed:
#!/bin/bash
# Check if minimal runtime has any setup scripts
ls -la runtimes/minimal/ubi9-python-3.12/ | grep -E "setup|sh$"
Length of output: 0
🏁 Script executed:
#!/bin/bash
# Check the datascience runtime for comparison
ls -la runtimes/datascience/ubi9-python-3.12/utils/
Length of output: 236
🏁 Script executed:
#!/bin/bash
# Look for any Elyra-related setup scripts in minimal runtime
fd -t f -e sh . runtimes/minimal/ubi9-python-3.12/
Length of output: 0
🏁 Script executed:
#!/bin/bash
# Check the PR changes to understand what was modified
git diff --stat HEAD~1 HEAD -- runtimes/minimal/
Length of output: 0
🏁 Script executed:
#!/bin/bash
# Check the datascience image to see if it has setup-elyra.sh
fd -t f "setup-elyra.sh" jupyter/datascience/ubi9-python-3.12/
Length of output: 51
🏁 Script executed:
#!/bin/bash
# Look at the setup-elyra.sh to confirm the cp approach
cat jupyter/datascience/ubi9-python-3.12/setup-elyra.sh | grep -A 3 -B 3 "bootstrapper"
Length of output: 261
🏁 Script executed:
#!/bin/bash
# Check what Dockerfile references the minimal runtime
rg -l "FROM.*runtime-minimal" --type dockerfile 2>/dev/null || rg -l "runtime-minimal" jupyter/
Length of output: 0
@jiridanek, perfect! ✅ The changes look great:
-
Version alignment issue resolved: The problematic
curldownloading v4.3.0 has been removed from the Dockerfile. -
Air-gapped build support maintained: The
setup-elyra.shscript now implements exactly what you suggested:cp /opt/app-root/lib/python3.12/site-packages/elyra/kfp/bootstrapper.py /opt/app-root/bin/utils/
-
Clean architecture: The minimal runtime serves as a base without Elyra-specific setup, and derived images (like datascience) handle the bootstrapper copy in their setup scripts after package installation.
This approach ensures the bootstrapper version always matches the installed odh-elyra package (4.3.1) and works perfectly in disconnected environments. The solution is maintainable and self-documenting with the comment acknowledging ELYRA_INSTALL_PACKAGES=false requirement. Nice work! 🎯
🧠 Learnings used
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#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.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T12:10:50.856Z
Learning: jiridanek requested GitHub issue creation for Dockerfile environment variable refactoring during PR #2215 review. Issue #2311 was created addressing build-only variables (OPENBLAS_VERSION, ONNX_VERSION, GRPC_PYTHON_BUILD_SYSTEM_OPENSSL) being unnecessarily written to /etc/profile.d/ppc64le.sh in runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu, causing variable duplication across stages, unreliable sourcing in non-login build contexts, and violation of DRY principles. The issue includes comprehensive problem description covering affected lines 30-37, detailed impact analysis of build reliability and maintenance overhead, three solution options with centralized ARG/ENV approach as recommended, clear acceptance criteria for version centralization and build-only variable cleanup, and specific implementation guidance with code examples, assigned to jiridanek, continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!
jiridanek
approved these changes
Oct 10, 2025
There was a problem hiding this comment.
@jesuino please also update elyra version in manifests, it is causing tests to fail
[checking the `notebook-python-dependencies` array] (pyproject=PosixPath('/home/runner/work/notebooks/notebooks/jupyter/pytorch+llmcompressor/ubi9-python-3.12/pyproject.toml')) SUBFAIL tests/test_main.py::test_image_pyprojects - AssertionError: Odh-Elyra: manifest /home/runner/work/notebooks/notebooks/manifests/base/jupyter-pytorch-llmcompressor-imagestream.yaml declares 4.2, but pylock.toml pins 4.3.1
assert (4, 3) == (4, 2)
https://github.com/opendatahub-io/notebooks/actions/runs/18386078682/job/52384729336?pr=2555
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jiridanek The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
New changes are detected. LGTM label has been removed. |
|
@jesuino ready for review / merge, or not yet? |
|
Hello @jiridanek We just finished sanity checks for Elyra 4.3.1 and no major issue was found. Feel free to go ahead and review/merge this. Thanks! |
… and correct directory handling
|
@jesuino: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
jiridanek
reviewed
Oct 10, 2025
| set -Eeuxo pipefail | ||
|
|
||
| # By copying this we must make sure that ELYRA_INSTALL_PACKAGES=false | ||
| cp /opt/app-root/lib/python3.12/site-packages/elyra/kfp/bootstrapper.py /opt/app-root/bin/utils/ |
There was a problem hiding this comment.
Good attempt, but it does not work
DEBUG root:workbench_image_test.py:239 cp: cannot create regular file '/opt/app-root/bin/utils/bootstrapper.py': Permission denied
the images don't start
jiridanek
reviewed
Oct 10, 2025
| set -x | ||
| set -Eeuxo pipefail | ||
|
|
||
| # By copying this we must make sure that ELYRA_INSTALL_PACKAGES=false |
There was a problem hiding this comment.
what will set this in runtime images? and what will copy the bootstrapper into place in runtime images? we don't have an entrypoint in runtime images
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This is a preparation for Elyra 4.3.0 release. It is a working in progress because we need Elyra to be released. Elyra 4.3.0 should be released from main branch, hence a few environment properties changes are required in order to avoid breaking the images that use Elyra.
This PR include the following changes:
bootstrapper.pyremoving the need of having a copy hereELYRA_INSTALL_PACKAGES=false) so it will work on air-gapped environmentsHow Has This Been Tested?
We are waiting images to be available so we can make Elyra sanity checks.
Summary by CodeRabbit