docs(adr): add ADR 0016 for à la carte AIPCC content delivery - #4359
docs(adr): add ADR 0016 for à la carte AIPCC content delivery#4359jiridanek wants to merge 1 commit into
Conversation
Record how the notebooks repository adopts AIPCC channel-based content identity (accel+torch+OS), Rolling/Stable maturity labels, lockfile-as- contract, and per-image channel selection decoupled from rhoai/<release>. Co-authored-by: Cursor <cursoragent@cursor.com>
github-actions
Bot
added
the
review-requested
|
@jiridanek — This PR is from a fork. Recommended: Push your branch to the main repo for full CI: Then open a new PR from that branch. No push access? A maintainer will cherry-pick and test your changes. See CONTRIBUTING.md for details. |
📝 WalkthroughWalkthroughThe ADR proposes channel-based AIPCC content delivery for notebook images. It defines fixed channel identities based on accelerator, torch version, and OS, with Rolling and Stable metadata labels. It establishes immutable timestamped base images and per-image lockfiles as release artifacts. It maps legacy release-plan concepts to channels, documents repository migration work, defines ABI-ceiling handling and EUS retention, and records related references. Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 11✅ Passed checks (11 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
Comment |
|
[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. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4359 +/- ##
=======================================
Coverage 44.29% 44.29%
=======================================
Files 46 46
Lines 5861 5861
Branches 977 977
=======================================
Hits 2596 2596
Misses 3045 3045
Partials 220 220
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
![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
🧹 Nitpick comments (1)
docs/architecture/decisions/0016-adopt-a-la-carte-content-delivery-for-aipcc-notebooks.md (1)
98-104: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick winMake GA channel adoption auditable.
The ADR requires per-channel GA registration and a durable adoption record, but the mechanism is marked TBD. Add the responsible role, record location, and completion criterion, or link a tracking issue with those exit criteria. Otherwise, a release can ship with correct repository pins but no evidence that AIPCC received the required adoption.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/architecture/decisions/0016-adopt-a-la-carte-content-delivery-for-aipcc-notebooks.md` around lines 98 - 104, Update the GA channel adoption section of the ADR to replace the “mechanism TBD” statement with an actionable process: identify the responsible role, specify where the durable channel and lockfile adoption record is stored, and define the evidence required to consider registration complete. Alternatively, link a tracking issue that explicitly contains those same exit criteria.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@docs/architecture/decisions/0016-adopt-a-la-carte-content-delivery-for-aipcc-notebooks.md`:
- Around line 193-203: Revise the “Channel support follows consumption” section
to define a single unambiguous formula: calculate each consumer’s end date as
the minimum of its release EOL, base-image support end, and upstream torch
support end, then set the channel end date to the maximum of those consumer end
dates. Clarify that LTS/EUS consumers use the 18-month timeline within this
calculation, and that channels without supported consumers follow the separately
specified minimum deprecation-notice window once Release Engineering sets it.
- Around line 180-191: Update the release-contract decision to define a
versioned, immutable release manifest for each image family, mapping it to an
immutable Git reference, exact lockfile, and base-image digest. Replace
references to the moving main or stable branch and post-GA lockfile updates as
the GA identity, and document the registry immutability guarantee if timestamp
tags remain the base-image identity.
---
Nitpick comments:
In
`@docs/architecture/decisions/0016-adopt-a-la-carte-content-delivery-for-aipcc-notebooks.md`:
- Around line 98-104: Update the GA channel adoption section of the ADR to
replace the “mechanism TBD” statement with an actionable process: identify the
responsible role, specify where the durable channel and lockfile adoption record
is stored, and define the evidence required to consider registration complete.
Alternatively, link a tracking issue that explicitly contains those same exit
criteria.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited), Repository UI (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 60e490b9-0532-45eb-9b31-44e91480081f
📒 Files selected for processing (1)
docs/architecture/decisions/0016-adopt-a-la-carte-content-delivery-for-aipcc-notebooks.md
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
opendatahub-io/kubeflow(manual)opendatahub-io/opendatahub-operator(manual)opendatahub-io/odh-dashboard(manual)
| ### Lockfile plus base image is the release contract | ||
|
|
||
| "What did RHOAI 3.6 GA ship?" is answered by **this repository's lockfile** | ||
| (Renovate/Dependabot-managed, on `main` or a stable branch) plus the immutable | ||
| timestamp-tagged RHAIBI base image referenced in `build-args/konflux.*.conf`. | ||
| AIPCC builds every compatible package version in a channel and retains published | ||
| versions for the channel's supported lifecycle; the lockfile pins exactly what a | ||
| release shipped and is fully reproducible against the channel. | ||
|
|
||
| Post-GA, ABI-compatible fixes (qualified CVEs and urgent bug fixes) flow through | ||
| channel updates. This team bumps its lockfile; RHOAI release management approves | ||
| each z-stream re-pin. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Make the release contract immutable and per-image.
Lines 81-82 define the release contract as a set of lockfiles and base-image pins. Lines 182-184 refer to a singular lockfile on main or a stable branch. Lines 189-191 allow that lockfile to change after GA. A moving branch cannot identify the GA snapshot.
Define a versioned release manifest that maps each image family to an immutable Git reference, exact lockfile, and base-image digest. If timestamp tags are the intended identity, document the registry immutability guarantee. Otherwise, the claim of full reproducibility is not valid.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@docs/architecture/decisions/0016-adopt-a-la-carte-content-delivery-for-aipcc-notebooks.md`
around lines 180 - 191, Update the release-contract decision to define a
versioned, immutable release manifest for each image family, mapping it to an
immutable Git reference, exact lockfile, and base-image digest. Replace
references to the moving main or stable branch and post-GA lockfile updates as
the GA identity, and document the registry immutability guarantee if timestamp
tags remain the base-image identity.
| ### Channel support follows consumption | ||
|
|
||
| A channel is supported while **any** product version that consumes it is | ||
| supported. Support duration is **capped** to the shortest of: the consuming | ||
| release branch's lifetime, base-image content support, and upstream torch | ||
| support — so consumers may be asked to move to a newer-torch channel at the next | ||
| release rather than maintaining aged-out torch streams indefinitely. Its end date | ||
| is the maximum of its consumers' EOLs. For LTS/EUS consumers, a channel they | ||
| consume is maintained to the LTS timeline (18 months). Channels no supported | ||
| release adopts are deprecated quickly, with a minimum deprecation notice (exact | ||
| window TBD with Release Engineering). |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift
Resolve the conflicting channel support rules.
Line 195 says a channel remains supported while any consuming product is supported. Lines 196-199 cap support at the shortest dependency lifetime. Line 200 then sets the channel end date to the maximum consumer EOL. These rules produce different dates.
Define one formula, such as consumer_end = min(release_eol, base_image_support_end, torch_support_end) and channel_end = max(consumer_end). State how the 18-month EUS rule and the TBD deprecation window apply. Without this clarification, a required channel can be retired too early or retained beyond its support boundary.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@docs/architecture/decisions/0016-adopt-a-la-carte-content-delivery-for-aipcc-notebooks.md`
around lines 193 - 203, Revise the “Channel support follows consumption” section
to define a single unambiguous formula: calculate each consumer’s end date as
the minimum of its release EOL, base-image support end, and upstream torch
support end, then set the channel end date to the maximum of those consumer end
dates. Clarify that LTS/EUS consumers use the 18-month timeline within this
calculation, and that channels without supported consumers follow the separately
specified minimum deprecation-notice window once Release Engineering sets it.
2 participants
Summary
cuda13.0-torch2.11-ubi9), Rolling/Stable maturity labels, lockfile + base image as the release contract, per-image channel selection, and mapping from the AIPCC Release Plan spreadsheet.Test plan
docs/architecture/decisions/format and numbering (0016)Made with Cursor
Summary by CodeRabbit