ComponentVersion: expose per-release resolved images in status (unknown keys are deliberately user-managed, but currently indistinguishable from typos)

[weicao]

Current behavior

• Image keys in ComponentVersion.spec.releases[*].images are matched case-insensitively against runtime container names, init container names, and lifecycle action names (pkg/controller/component/component_version.go:304-340, main @ aa7f8c8). A key that matches nothing (e.g. a typo like swichover, or a container renamed in a newer CMPD) is silently carried along and never applied — no validation error, no event, no status message.
• ComponentVersion.status only exposes observedGeneration, phase, message, serviceVersions. There is no per-release view of which images were actually resolved for which containers/actions.

Why it matters

Image-key typos and container renames are only discoverable by observing that a Pod or action still runs the old image after an upgrade — a long diagnosis chain. Addon upgrade acceptance currently has to diff Pod/action images manually per release.

Suggested fix

1. During ComponentVersion reconciliation (or admission), cross-check each release's image keys against the containers/actions of the ComponentDefinitions matched by compatibilityRules; surface unmatched keys as a condition/warning (a hard error may be too strict since one CMPV can span CMPDs with different container sets).
2. Optionally extend status with resolved images per (release, compDef) so upgrade verification can read it instead of inspecting Pods.

[weicao]

Concrete proposal (offering to implement once maintainers pick the strictness):

The wrinkle with a hard admission error is that one ComponentVersion's compatibilityRules can span ComponentDefinitions with different container/action sets, so a key that is unknown for CMPD-A may be valid for CMPD-B. Suggested shape:

1. Reconcile-time warning, not admission error: in the ComponentVersion controller, for each release cross-check every image key against the union of container names + init container names + lifecycle action names of all CMPDs matched by the release's compatibilityRules (matching case-insensitively, same normalization as findMatchedImagesFromCompVersions, pkg/controller/component/component_version.go:304-340). Keys matching nothing in ANY matched CMPD → add a condition (e.g. UnresolvedImageKeys) listing them, and emit a Warning event. Phase stays Available (non-breaking).
2. Status enrichment: extend status.serviceVersions or add status.resolvedImages summarizing per (release, compDef) which keys applied. This also gives upgrade acceptance a place to read resolved action images instead of inspecting Pods.

Step 1 alone catches the typo case (swichover) with zero compatibility risk; step 2 is additive. Happy to send the PR for step 1 first if that direction is agreed.

[weicao]

Correction to my proposal above, after reading the ComponentVersion controller more carefully: unknown image keys are deliberately allowed — validateImageContainer (controllers/apps/componentversion_controller.go:343-351) checks containers and lifecycle actions, then explicitly returns nil for anything else with the comment "user-managed images, leave it to the user to handle". So a keys-must-match warning condition (my step 1) would false-positive on that intended use case and should be dropped.

The remaining valid ask from this issue is observability only (my step 2): expose per-release resolved images (which keys applied to which container/action, which were left as user-managed) in ComponentVersion status, so typos like swichover become visible as "resolved to nothing / treated as user-managed" instead of requiring Pod inspection. Feel free to retitle accordingly.