[dmitry-tokarev-nv]

Linear: OPS-9079

Summary

• Move the planner runtime base from nvcr.io/nvidia/distroless/python:3.13-v4.1.9 (Python 3.13.16) to 3.13-v4.1.10 (Python 3.13.18). Move the builder from python:3.13.17-slim to python:3.13.18-slim (container/context.yaml).
• Re-capture the distroless baseline SBOM for amd64 and arm64 with capture_baseline_sbom.py --prune-superseded. The new files are python@c718fc95-amd64.cdx.json and python@c718fc95-arm64.cdx.json. Against the old files, only three components change: python (3.13.16 to 3.13.18), tzdata and tzdata-legacy (2026c to 2026e).
• Remove the temporary copy of the builder's ensurepip from the final stage. The new runtime's own ensurepip bundles pip 26.2.2.
• Keep the build-time check after it. It now tests the runtime's own ensurepip, so a base with an older bundled pip fails the build.

Closes #17188

Validation

Each base, on amd64, with the final stage as it is in this PR (no ensurepip copy):

Runtime base	Python	ensurepip pip	Build-time check	pip in a new venv
3.13-v4.1.9	3.13.16	26.2.1	AssertionError	26.2.1
3.13-v4.1.10	3.13.18	26.2.2	passes	26.2.2

• Startup on amd64: I copied the payload of the main-dynamo-planner image (7e44a1dfea) onto 3.13-v4.1.10, the same way the final stage does. As uid 1000, python -m dynamo.planner --help, python -m dynamo.profiler --help and python -m dynamo.global_planner --help exit 0. The venv runs Python 3.13.18.
• capture_baseline_sbom.py: on both architectures, 50 of 50 baseline layers form a prefix, and the license policy check passes.
• check_drift.py: all 14 tracked base images are current.
• container/render.py --target planner renders, with BASELINE_SBOM_FILE="python@c718fc95".
• pre-commit run --all-files: 40 hooks passed.
• The image that CI built for this PR (d2e8d01702), on amd64 and arm64: PY_VERSION is 3.13.18, and ensurepip bundles pip-26.2.2-py3-none-any.whl. On amd64, --help of the planner, profiler and global planner exits 0. The planner build, compliance and CPU test jobs passed on both architectures.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes
  • Planner environments now retain the runtime image’s bundled Python installer support, with pip verified in a created virtual environment.
• Chores
  • Updated the planner’s build and runtime container images and refreshed their software bill of materials.

[coderabbitai]

Walkthrough

The planner build and runtime Python base references are updated. The runtime Dockerfile now uses its bundled ensurepip module, and the baseline SBOM records match the updated runtime image.

Changes

Planner Python base

Layer / File(s)	Summary
Update Python bases and runtime setup container/context.yaml, container/templates/planner.Dockerfile, container/compliance/base_sboms/manifest.json	The build and runtime image tags and baseline SBOM reference are updated. The runtime no longer copies ensurepip from the builder; the following check validates the runtime module and pip-enabled virtual environment. The SBOM records use the updated runtime image digest.

Estimated code review effort: 2 (Simple) | ~10 minutes

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title names the change: moving the planner Python bases to 3.13.18. The changeset updates the runtime base to 3.13-v4.1.10 (Python 3.13.18), the builder to python:3.13.18-slim, refreshes the basel…
Linked Issues check		Linked issue #17188 is the only direct target. Its coding requirements are met at the reviewed head: 1. Update runtime base and align builder to 3.13.17 or newer. Met. container/context.yaml sets pla…
Out of Scope Changes check		All changes connect to the base and builder upgrade in #17188: - container/context.yaml: tag bumps for the builder and runtime, and the planner_baseline_sbom identifier that must match the refreshed …
Description check		The description is detailed and covers the change overview, key implementation changes, validation results, and linked issue closure. It does not use every template heading and omits the pull request …

Full details: Title check

Explanation

The title names the change: moving the planner Python bases to 3.13.18. The changeset updates the runtime base to 3.13-v4.1.10 (Python 3.13.18), the builder to python:3.13.18-slim, refreshes the baseline SBOMs, and removes the temporary ensurepip copy. The title covers the main change but does not mention the ensurepip removal. It also uses a conventional-commit prefix and a ticket ID, which is acceptable.

Full details: Linked Issues check

Explanation

Linked issue #17188 is the only direct target. Its coding requirements are met at the reviewed head:

1. Update runtime base and align builder to 3.13.17 or newer. Met. container/context.yaml sets planner_runtime_image_tag to 3.13-v4.1.10 (Python 3.13.18) and planner_build_image_tag to 3.13.18-slim.

2. Remove the temporary ensurepip copy. Met. container/templates/planner.Dockerfile removes the rmtree step, the COPY --from=planner_builder of ensurepip, and the comment that referenced #17188. The diff shows -4 lines and no added lines in this area.

3. Remove associated checks. Interpreted as met. The build-time check (ensurepip version >= 26.2.2, one bundled pip wheel, venv with pip, pip --version) is kept unchanged in the Dockerfile. It now tests the runtime's own ensurepip rather than a copied one. Its purpose is the venv-with-pip verification that #17188 asks for. The PR states the retained check is deliberate. A reader who reads 'associated checks' as the check itself would see this item as unmet.

4. Verify venv creation with pip and planner/profiler startup on amd64 and arm64. Partly evidenced. The PR reports amd64 venv creation (pip 26.2.2) and amd64 startup for dynamo.planner, dynamo.profiler, and dynamo.global_planner. arm64 was not run locally. The planner-build CI job is stated to build both architectures and run the final-stage check. That CI result was not available for inspection.

The code changes satisfy the coding objectives. Remaining uncertainty is the arm64 verification, which depends on CI results outside this review.

Full details: Out of Scope Changes check

Explanation

All changes connect to the base and builder upgrade in #17188:

• container/context.yaml: tag bumps for the builder and runtime, and the planner_baseline_sbom identifier that must match the refreshed SBOM.
• container/templates/planner.Dockerfile: ensurepip copy removal and the retained runtime-ensurepip check. Both are direct parts of #17188.
• container/compliance/base_sboms/manifest.json (+11/-11): updated tag, digest, and SBOM filenames for amd64 and arm64, plus a generated_at timestamp. These records follow from the base image change and are required for the baseline SBOM lookup.

The new SBOM files (python@c718fc95-amd64.cdx.json, python@c718fc95-arm64.cdx.json) were not opened. Their content is generated and was not needed to judge scope. No unrelated code or configuration change was found in the reviewed diffs.

Full details: Description check

Explanation

The description is detailed and covers the change overview, key implementation changes, validation results, and linked issue closure. It does not use every template heading and omits the pull request checklist, but the required technical information is mostly complete.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Warning

Review coverage is incomplete: 2 files could not be fully reviewed. Findings from completed review steps are included; see review info for details.

Tip

🎯 Customize your risk assessments

Guide how CodeRabbit assesses merge risk and security architecture risk. Highlight sensitive changes and explain your security boundaries using Merge Risk Instructions and Security Risk Instructions in your review settings. Security architecture risk assessments require the Advanced plan or above.

✅ Automatic approvals, with your rules

Let CodeRabbit approve pull requests once required threads are resolved, pre-merge checks pass, and your risk limits are met. Enable Automatic approvals in review settings, with overrides for teams or file paths.

CodeRabbit Verify

• Run CodeRabbit Verify to test the changes in this pull request.

Recent review info

Run configuration

• Source mode: Auto
• Repository: ai-dynamo/dynamo
• Branch: main
• File: .coderabbit.yaml
• Commit: d7fecab
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Enterprise
• Run ID: 2b47751c-f992-4b45-8ece-2e050d2ee3a3

Commits

Reviewing files that changed from the base of the PR and between d7fecab and d2e8d01.

Files selected for processing: 5

• container/compliance/base_sboms/manifest.json
• container/compliance/base_sboms/python@c718fc95-amd64.cdx.json
• container/compliance/base_sboms/python@c718fc95-arm64.cdx.json
• container/context.yaml
• container/templates/planner.Dockerfile

Files with no reviewable changes: 1

• container/templates/planner.Dockerfile

Files not fully reviewed because their changes were unavailable: 2

• container/compliance/base_sboms/python@c718fc95-amd64.cdx.json
• container/compliance/base_sboms/python@c718fc95-arm64.cdx.json

Included review availability: This review used your included allowance. Your plan provides up to 12 included reviews per hour; 11 remain after this review.

[devin-ai-integration]

❌ Dynamo PR CI failed — run 41586106881 (attempt 1) on d2e8d01702

Gate checks: ✅ backend-status-check · ❌ deploy-status-check · ✅ dynamo-status-check

Framework	Snapshot
SGLang	❌ 1

Failure details

1 job failed: the SGLang Snapshot vCluster setup timed out because 2 of the vcluster-hpm-hostpath-mapper DaemonSet pods never started on their GPU nodes (infrastructure). No tests ran.

❌ SGLang Snapshot Operator Setup: vcluster-hpm-hostpath-mapper DaemonSet rollout timeout (2 pods stuck Pending)

Job: SGLang Snapshot Operator Setup · Failed step: Setup vCluster and operator · Logs: gh run view --job 125757903603 -R ai-dynamo/dynamo --log-failed

ready.go:336: [debug] DaemonSet is not ready: gh-id-41586106881-checkpoint-sglang-dt/vcluster-hpm-hostpath-mapper. 4 out of 5 expected pods are ready
wait.go:87: [debug] Error received when checking status of resource vcluster-hpm-hostpath-mapper. Error: 'client rate limiter Wait returned an error: context deadline exceeded'
Error: context deadline exceeded
##[error]Process completed with exit code 1.
### VCLUSTER OPERATOR DEPLOYMENT FAILED
vcluster-hpm-hostpath-mapper-4r55g   0/1   Pending   0   10m   <none>   aks-a100a-56471985-vmss000002
vcluster-hpm-hostpath-mapper-tzrjp   0/1   Pending   0   10m   <none>   aks-a100b-21135548-vmss000001
Events:
  Normal  Scheduled  10m  default-scheduler  Successfully assigned .../vcluster-hpm-hostpath-mapper-4r55g to aks-a100a-56471985-vmss000002

The 600s rollout wait for the vcluster-hpm-hostpath-mapper DaemonSet timed out. Two pods were scheduled to GPU nodes aks-a100a-56471985-vmss000002 and aks-a100b-21135548-vmss000001 but stayed Pending with no IP and no events after Scheduled, which suggests those nodes were not starting pods. This is an infrastructure/cluster failure unrelated to the PR's code. Rerunning the failed jobs will likely fix it.

For agents

{"pr": 17915, "run_id": 41586106881, "run_attempt": 1, "head_sha": "d2e8d01702d6a5e923922e271cac68b7796e79e1",
 "failures": [{"job": "SGLang Snapshot Operator Setup", "job_id": 125757903603, "failed_step": "Setup vCluster and operator", "signature": "vcluster-hpm-hostpath-mapper DaemonSet rollout timeout: context deadline exceeded (2 pods Pending on GPU nodes)", "tests": [], "log_cmd": "gh run view --job 125757903603 -R ai-dynamo/dynamo --log-failed"}]}

_{Posted automatically by Devin for run 41586106881. Updated on every full-CI run of this PR.}