feat(recipes): requalify and re-pin k8s-aibom to v1.3.0 - #2309
Merged
Merged
Conversation
Re-runs all four ADR-019 adoption gates against the upstream graduation release and moves the registry pin to it. Per Decision 4 the chart, image, CRDs, and public status contract are one versioned set, so a CRD change requires requalification rather than a version bump. Qualified set: source v1.3.0 at 30af41abbe0bed3c41a42289ccf294be8c4779bb, chart 1.3.0 at sha256:4ffa933e..., image sha256:f8e48d4e.... Gate findings that changed AICR-visible behavior: Rendered RBAC is byte-identical to 1.2.0, so no permission change accompanies the graduation. The rendered resource set is unchanged and the chart still renders AIBOMControllerConfig at aibom.k8saibom.dev/v1alpha1. Only CRD storage moved to v1beta1. The health check now reflects that asymmetry deliberately: both CRD storage assertions flip to v1beta1 while the controller-config step keeps reading v1alpha1. Replacing every v1alpha1 occurrence would have broken it. The readiness fixes ship in the image, not the chart. Probe configuration renders identically across the two versions, so the corrected readiness behavior is obtained only by re-pinning the image digest, which is the substantive half of this change. The health-check test helper now builds each CRD in the shape its chart actually ships (1.3.0 serves both versions with storage on v1beta1; 1.2.0 and earlier serve only v1alpha1), so a stranded case models a real pre-upgrade cluster rather than an invented hybrid. Also corrects a stale comment missed in #2305: the partial-apply test case still attributed that state to AICR's documented CRD-apply step, a claim that was tested and retracted there. The regenerated BOM additionally picks up an unrelated ubuntu:26.04 digest that #2301 changed in a rendered manifest without regenerating the doc. Fixes: #2282 Related: #2271, #2264 Signed-off-by: Mark Chmarny <mark@chmarny.com>
mchmarny
added
theme/recipes
mchmarny
enabled auto-merge (squash)
August 20, 2026 16:03
Contributor
|
🌿 Preview your docs: https://nvidia-preview-feat-aibom-requalify-v1-3-0.docs.buildwithfern.com/aicr |
Contributor
Recipe evidence check
No leaf overlays affected by this PR. This gate is warning-only and never blocks merge. |
njhensley
approved these changes
Aug 20, 2026
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Enterprise Run ID: 📒 Files selected for processing (7)
Included review availability: Your plan provides up to 12 included reviews per hour; 11 remain after this review. 📝 WalkthroughWalkthroughThe PR requalifies k8s-aibom against chart version 1.3.0. It updates source, chart, image, and digest pins, records the v1beta1 CRD storage transition, and refreshes Kubernetes support documentation. The health check now asserts v1beta1 storage. Chainsaw fixtures cover pre-upgrade and partially upgraded CRD states. Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to This PR requalifies and re-pins the k8s-aibom chart and image to v1.3.0 while updating the related health checks and documentation; no actionable merge-blocking risk remains after normal checks and review. Suggested reviewers: 🚥 Pre-merge checks | ✅ 3 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (3 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Contributor
Coverage Report ✅
Coverage BadgeNo Go source files changed in this PR. |
This was referenced Aug 20, 2026
mchmarny
added a commit
that referenced
this pull request
Aug 21, 2026
The ADR-019 requirement-status table pointed the upgrade-evidence row at #2282, which closed as the requalification and never carried that evidence, and the managed-cluster row at the epic rather than the issue. Point both at the issues that track them: #2310 and #2311. The component values still described the pinned digest as a v1.2.0 artifact set after #2309 moved it to v1.3.0, and stated the Kind-measured resource envelope without saying it was Kind, or that neither the v1.3.0 image nor a managed control plane has been re-measured against it. Signed-off-by: Mark Chmarny <mark@chmarny.com>
mchmarny
added a commit
that referenced
this pull request
Aug 21, 2026
Two places in the record went stale when #2309 re-pinned k8s-aibom to chart v1.3.0. ADR-019's requirement-status table pointed the upgrade-evidence row at #2282, which closed as the requalification and never carried that evidence, and pointed the managed-cluster row at the epic rather than the issue tracking it. Both now point at #2310 and #2311, which have since closed with that evidence. The component values described the pinned digest as a v1.2.0 artifact set after the re-pin moved it to v1.3.0, and stated a Kind-measured resource envelope that had never been checked against a managed control plane. #2310 measured it: 67-69MiB and 1-2m steady-state CPU at 1,001 workloads on GKE, well inside the declared requests. The v1.2.0 Kind figures are dropped rather than carried forward as a comparison, since the upgrade validation they existed for is complete. Signed-off-by: Mark Chmarny <mark@chmarny.com>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
Summary
Re-runs all four ADR-019 adoption gates against upstream v1.3.0, the API-graduation release, and moves the registry pin to it.
Motivation / Context
ADR-019 Decision 4: chart, image, CRDs, and the public status contract are one versioned set, and a CRD change requires requalification rather than a version bump. v1.3.0 adds
v1beta1alongsidev1alpha1and moves CRD storage to it, so this is a requalification.Fixes: #2282
Related: #2271, #2264
Type of Change
Component(s) Affected
cmd/aicr,pkg/cli)cmd/aicrd,pkg/server)pkg/recipe)pkg/bundler,pkg/component/*)pkg/collector,pkg/snapshotter)pkg/validator)pkg/errors,pkg/k8s)docs/,examples/)Implementation Notes
Qualified artifact set
v1.3.0at30af41abbe0bed3c41a42289ccf294be8c4779bbghcr.io/googlecloudplatform/k8s-aibom@sha256:f8e48d4edc44e6ee8e40a2ac6c5f60b190aa18d411a75702dc5798a77a039e8doci://ghcr.io/googlecloudplatform/charts/k8s-aibom:1.3.0atsha256:4ffa933e272a977e0b60f2eca1c4326176e6196e2ee69e1bf4f72c8b5a511c90Gate 1 — release and supply chain
Three attestations verified with
gh attestation verify --owner GoogleCloudPlatform --deny-self-hosted-runners, inspected as JSON rather than trusting the exit code:https://slsa.dev/provenance/v1refs/tags/v1.3.030af41ab…https://cyclonedx.org/bomrefs/tags/v1.3.0https://slsa.dev/provenance/v1refs/tags/v1.3.030af41ab…Build config resolves to the upstream
release.yamlworkflow inGoogleCloudPlatform/k8s-aibom.Gate 2 — Helm and Kubernetes lifecycle
Rendered both versions against our
values.yaml. Resource set is unchanged: ServiceAccount, ClusterRole, ClusterRoleBinding, Deployment, AIBOMControllerConfig. The only template differences arehelm.sh/chartandapp.kubernetes.io/versionlabels.The chart still renders
AIBOMControllerConfigataibom.k8saibom.dev/v1alpha1. Only CRD storage moved. This is the finding that shaped the health-check change below — a blanketv1alpha1→v1beta1replacement would have broken the check against a correctly-deployed cluster.Also confirmed
readiness.strictConfig: truestill reaches the rendered output as the container arg--strict-config-readiness; it is a controller flag, not a CR spec field.Gate 3 — security, RBAC, privacy
Rendered RBAC diffed 1.2.0 → 1.3.0: byte-identical. No permission change accompanies the graduation.
Gate 4 — operational safety
The readiness fixes ship in the image, not the chart. Probe configuration renders identically across both versions, so the corrected readiness behavior (upstream's start-ordering race fix plus the per-probe informer assertion) is obtained only by re-pinning the image digest. That is the substantive half of this change and the reason a chart-version-only bump would have been wrong.
Health check
Both CRD storage assertions flip to
v1beta1; the controller-config step deliberately keeps readingv1alpha1, with a comment explaining the asymmetry so it is not "fixed" later.The test helper now builds each CRD in the shape its chart actually ships — 1.3.0 serves both versions with storage on
v1beta1, 1.2.0 and earlier serve onlyv1alpha1��� so a stranded case models a real pre-upgrade cluster rather than an invented hybrid. The four CRD cases invert accordingly, which is itself evidence they were testing the literal rather than something incidental.Also corrects a stale comment missed in #2305: the partial-apply case still attributed that state to AICR's documented CRD-apply step, a claim tested and retracted on that PR.
Deliberately out of scope
Cross-boundary upgrade, rollback, and uninstall evidence on real GKE. That is an ADR-019 Follow-Up Decisions requirement governing stock adoption, not a Decision 4 requalification requirement — I had over-scoped #2282 by folding it in. It moves to its own issue under #2271, where the real-GKE demo already needs a cluster.
One unrelated line
The regenerated BOM also picks up an
ubuntu:26.04digest that #2301 changed in a rendered manifest without regenerating the doc — the same gate gap that brokeTestStockRenderParityGoldenonmainearlier today.make bom-docsregenerates wholesale, so it cannot be excluded without leaving the doc inconsistent.Testing
Codebase qualification completed, no failures.Verified the storage-version flip is load-bearing: reverting the two literals to
v1alpha1fails the healthy case and every negative case'swantOutputassertion, because the default CRD fixture now models 1.3.0.Gate commands are reproducible from the tables above; chart renders were compared with
helm templateagainst the committedvalues.yaml.Risk Assessment
No stock recipe references
k8s-aibom, so no stock recipe changes. Medium rather than low because existing adopters on a custom recipe move to a new chart and image on their next bundle, and clusters upgrading through Helm, Helmfile, or Flux must apply the new CRDs first — the storage version genuinely changes here, which is precisely what the health check added in #2305 now detects.Rollout notes: Adopters upgrading through Helm, Helmfile, or Flux must run the pre-upgrade CRD step documented in the component catalog. Argo CD applies CRDs each sync and needs nothing. Without it the health check fails naming the stranded CRD, which is the intended behavior.
Checklist
make testwith-race)make lint)git commit -S)