You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Closes the last open ADR-019 Follow-Up requirement: stock adoption needs
"generation-time, recipe-recorded selection and opt-out semantics".
ADR-019 rejects a bundle-time --set k8s-aibom:enabled=false as a selection
contract because it changes neither the recipe nor its health checks. This
adds --runtime-inventory enabled|disabled, modelled on the existing
--slurm-accounting-mode selection rather than invented: the mode is recorded
as configuration.runtimeInventory.mode, the recipe apiVersion becomes
ConfiguredRecipeResultAPIVersion, and the component's ref carries
install: false. ComponentRef.IsEnabled already reads that key, so the
component leaves the resolved set, the bundle, and deployment validation.
The health-check half comes for free: the check lives on the component's own
ref, so disabling the component removes it. That is simpler than the Slurm
precedent, which has to append and omit a check on a sibling component.
Selecting a mode on a recipe that does not declare the component is an error,
not a silent no-op. Wrong criteria, a typo, or a recipe that never carried it
should surface rather than record a decision the recipe cannot honor. The
guard runs before Configuration is written so a rejected build leaves no
partial record, and unlike the accounting precedent it cannot be validated
from criteria alone, so it lives in applyBuildConfig rather than
resolveBuildConfig.
The same selection is available in AICRConfig at
spec.recipe.configuration.runtimeInventory.mode, with the flag taking
precedence, mirroring how accounting mode resolves.
Verified end to end against the generated CLI: disabled records the mode and
the bundler omits the component entirely; enabled records it and keeps the
component; a recipe without the component and an invalid value both fail with
actionable messages.
RecipeConfiguration now has two entries, one bespoke selection per optional
component. That boundary is written into the ADR amendment: a generic
per-component disable would need a policy for which components may be
declined at all, and nothing should let a recipe decline gpu-operator. A third
entry is the signal to revisit.
Fixes: #2271
Signed-off-by: Mark Chmarny <mark@chmarny.com>
| `--profile` | | string | Profile selection in exact `name=value` form (e.g. `gpuStack=operator-managed` on AKS or `gpuStack=driver-installer` on GKE); omit to use the declaration's default (`gpuStack=azure-managed` on AKS, `gpuStack=gke-default` on GKE) |
0 commit comments