Skip to content

Make AI BOM a recipe-level opt-in across all GKE recipes #2962

Description

@mchmarny

Goal

Make k8s-aibom available as an explicit, recipe-recorded opt-in across all stock GKE recipes, including inference and training recipes, regardless of platform or workload type.

Today only h100-gke-cos-inference includes the component in a stock recipe. Other recipes can add it through a custom overlay, but --runtime-inventory enabled cannot add a component that the resolved recipe does not already declare. This issue extends the stock selection path without making AI BOM default-on across GKE.

Scope

  • Record the GKE recipe scope, selection semantics, and qualification gates. ADR-019 stays as written, because ADRs here are point-in-time records; the #2976 description is the record of the change. Preserve the existing single-recipe default unless a separate decision changes it.
  • Let generation-time opt-in add k8s-aibom to any stock GKE recipe and record that selection in the emitted recipe. An explicit recipe-level decline must still be respected. The three GKE dynamo recipes (h100, b200, gb200) decline it, because k8s-aibom alongside grove and dynamo-platform has not been qualified.
  • Keep namespace observation opt-in under the upstream controller configuration. Recipes that do not select the component must not gain its CRDs, RBAC, runtime cost, or health checks.
  • Qualify the exact upstream chart and image release used, with rendered bundle and validation coverage for every GKE recipe that can opt in. Live managed-GKE evidence is the chart-level runs in feat(recipes): add k8s-aibom GKE opt-in and upgrade to v1.5.1 #2976, upstream's 1,002-workload run, and a granted recipe end to end in the GKE H100 training UAT lane (Kubeflow). Other recipes that can opt in rely on render and validation. On training recipes, default discovery matches inference runtimes only, so the live question there is install and coexistence, not inventory content. Record controller and API-server cost plus upgrade, rollback, and uninstall behavior.
  • Document the supported opt-in flow and its limits.

Done when

  • Every stock GKE recipe that does not explicitly decline the component can opt in at recipe generation; the choice survives bundle and validation, and absent opt-in leaves current behavior unchanged.
  • Tests cover GKE recipe selection, explicit declines, render parity, and no unintended adoption by other services.
  • The qualification evidence names the covered recipes and supports the expanded scope.

Out of scope

Default-on expansion to additional recipes, opt-in support for non-GKE services, and k8s-aibom on the GKE dynamo recipes. Each needs separate scope and qualification decisions.

Related: #2271 (single stock recipe), #2234 (registry-only component adoption).


Edited 2026-09-30: dropped the ADR-019 amendment (ADRs are point-in-time; #2976 is the record), named the dynamo decline, and replaced per-combination live evidence with chart-level runs plus one UAT lane, with the reason.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions