AIPCC-6903: workaround(ROCm): fix permissions in ROCm images to account for AIPCC way of setting permissions in rocm base (#1682) #2661
Conversation
…nt for AIPCC way of setting permissions in rocm base (opendatahub-io#1682) (cherry picked from commit 25f1b89)
github-actions
bot
added
the
review-requested
WalkthroughAdds explicit root (USER 0) execution blocks around package installation and setup in multiple Dockerfiles, then switches back to non-root (USER 1001); includes permission adjustments, Jupyter configuration steps, and WORKDIR updates in Jupyter and runtime ROCm/CUDA images. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
jupyter/minimal/ubi9-python-3.12/Dockerfile.rocm(2 hunks)jupyter/rocm/pytorch/ubi9-python-3.12/Dockerfile.rocm(2 hunks)jupyter/rocm/tensorflow/ubi9-python-3.12/Dockerfile.rocm(2 hunks)runtimes/rocm-pytorch/ubi9-python-3.12/Dockerfile.rocm(2 hunks)runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm(2 hunks)runtimes/tensorflow/ubi9-python-3.12/Dockerfile.cuda(2 hunks)
⏰ 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). (20)
- GitHub Check: Red Hat Konflux / odh-workbench-jupyter-minimal-cpu-py312-ubi9-on-pull-request
- GitHub Check: Red Hat Konflux / odh-workbench-jupyter-minimal-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-pipeline-runtime-pytorch-rocm-py312-ubi9-on-pull-request
- GitHub Check: build (jupyter-minimal-ubi9-python-3.12, 3.12, linux/ppc64le, false) / build
- GitHub Check: build (rocm-jupyter-minimal-ubi9-python-3.12, 3.12, linux/amd64, false) / build
- GitHub Check: build (runtime-cuda-tensorflow-ubi9-python-3.12, 3.12, linux/amd64, false) / build
- GitHub Check: build (rocm-jupyter-pytorch-ubi9-python-3.12, 3.12, linux/amd64, false) / build
- GitHub Check: build (cuda-jupyter-minimal-ubi9-python-3.12, 3.12, linux/arm64, false) / build
- GitHub Check: build (runtime-cuda-tensorflow-ubi9-python-3.12, 3.12, linux/arm64, false) / build
- GitHub Check: build (rocm-jupyter-tensorflow-ubi9-python-3.12, 3.12, linux/amd64, false) / build
- GitHub Check: build (jupyter-minimal-ubi9-python-3.12, 3.12, linux/s390x, false) / build
- GitHub Check: build (jupyter-minimal-ubi9-python-3.12, 3.12, linux/amd64, false) / build
- GitHub Check: build (cuda-jupyter-minimal-ubi9-python-3.12, 3.12, linux/amd64, false) / build
- GitHub Check: build (rocm-runtime-pytorch-ubi9-python-3.12, 3.12, linux/amd64, false) / build
- GitHub Check: build (rocm-runtime-tensorflow-ubi9-python-3.12, 3.12, linux/amd64, false) / build
- GitHub Check: Red Hat Konflux / odh-workbench-jupyter-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-minimal-rocm-py312-ubi9-on-pull-request
- GitHub Check: Red Hat Konflux / odh-pipeline-runtime-tensorflow-rocm-py312-ubi9-on-pull-request
🔇 Additional comments (5)
runtimes/rocm-pytorch/ubi9-python-3.12/Dockerfile.rocm (1)
88-105: Consistent user context and permission pattern.The changes correctly bracket the installation block with USER 0 before and USER 1001 after, with a single permission-hardening RUN block applied. This aligns with OpenShift-friendly security practices.
jupyter/rocm/tensorflow/ubi9-python-3.12/Dockerfile.rocm (1)
160-192: Consistent user context and permission pattern.The changes correctly bracket the installation block with USER 0 and switch to USER 1001 after, with a single permission-hardening step. The post-install link-solibs operation executes under non-root context.
runtimes/tensorflow/ubi9-python-3.12/Dockerfile.cuda (1)
91-107: Consistent user context and permission pattern.The changes correctly manage user context with USER 0 for installation and USER 1001 for subsequent operations, applying a single permission-hardening block. Pattern is consistent across similar runtime images.
runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm (1)
87-104: Consistent user context and permission pattern.The changes maintain consistent user context switching with a single permission-hardening block. Pattern aligns with other updated runtime images in this PR.
jupyter/rocm/pytorch/ubi9-python-3.12/Dockerfile.rocm (1)
159-188: Consistent user context with comprehensive setup block.The changes bracket a comprehensive installation and runtime-configuration sequence under USER 0, then switch to USER 1001 for subsequent operations. Permission hardening is applied once within the root context. Pattern is consistent across the PR.
|
@coderabbitai please review Pay special attention to: |
jiridanek
added
the
tide/merge-method-squash
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 32747 @jiridanek I've completed a comprehensive review of all 6 Dockerfiles. Here are my findings: ✅ USER Transitions (USER 0 ↔ USER 1001)All files correctly pair and order USER directives: Pattern observed across all files:
Notable examples:
✅ Permission Changes (chmod, fix-permissions)All permission operations are correctly placed: Consistent pattern in all files: USER 0
RUN /bin/bash <<'EOF'
# ... package installation ...
chmod -R g+w /opt/app-root/lib/python3.12/site-packages
fix-permissions /opt/app-root -P
EOF
USER 1001Key observations:
✅ WORKDIR PlacementAll files correctly place WORKDIR directives: Pattern: USER 0
RUN # ... installations and permission fixes ...
USER 1001
WORKDIR /opt/app-root/srcFiles reviewed:
This prevents permission mismatches - the working directory is set after switching to the runtime user. ✅ Hardcoded Paths and UID/GID AssumptionsAll paths use standard OpenShift conventions: Standard paths used:
No problematic assumptions found:
Additional ObservationsMinor note on COPY placement:
Conclusion✅ All USER 0 and USER 1001 transitions are correctly paired and ordered The changes successfully implement the ROCm permissions workaround while maintaining proper OpenShift security practices. The implementation is consistent across all 6 Dockerfiles. |
|
@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. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: ide-developer 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 |
2 participants
(cherry picked from commit 25f1b89)
Description
https://issues.redhat.com/browse/AIPCC-6903
How Has This Been Tested?
Self checklist (all need to be checked):
make test(gmakeon macOS) before asking for reviewDockerfile.konfluxfiles should be done inodh/notebooksand automatically synced torhds/notebooks. For Konflux-specific changes, modifyDockerfile.konfluxfiles directly inrhds/notebooksas these require special attention in the downstream repository and flow to the upcoming RHOAI release.Merge criteria:
Summary by CodeRabbit