Context
From PR #72 review feedback by @Lytol: the current additionalRuntimeImages field only allows appending to the hardcoded default images. It doesn't let operators override or remove the built-in defaults.
It could be useful to set all images explicitly, falling back to sensible defaults if none are specified.
Current Behavior
- Default runtime images are hardcoded in
DefaultRuntimeYAML()
additionalRuntimeImages appends to those defaults- No way to remove or replace a hardcoded default image without an operator code change
Proposed Behavior
Allow operators to explicitly define the full set of runtime images, with the current hardcoded list used only as a fallback when no explicit images are specified.
Design Considerations
- Full replace semantics: operators must re-specify every image they want, but new defaults from operator upgrades won't appear automatically
- Additive model (current): safer, but no way to drop stale defaults
- Possible middle ground: a
runtimeImages field for full replacement alongside additionalRuntimeImages for appending, or a single field with a mode selector
References
Context
From PR #72 review feedback by @Lytol: the current
additionalRuntimeImagesfield only allows appending to the hardcoded default images. It doesn't let operators override or remove the built-in defaults.It could be useful to set all images explicitly, falling back to sensible defaults if none are specified.
Current Behavior
DefaultRuntimeYAML()additionalRuntimeImagesappends to those defaultsProposed Behavior
Allow operators to explicitly define the full set of runtime images, with the current hardcoded list used only as a fallback when no explicit images are specified.
Design Considerations
runtimeImagesfield for full replacement alongsideadditionalRuntimeImagesfor appending, or a single field with a mode selectorReferences