compDef pattern multi-match resolution is silent: sorted-last selection with no warning, condition, or event

[weicao]

Current behavior

compDef references (ClusterDefinition topology components, ComponentVersion compatibilityRules, and other prefix/regex reference sites) resolve multi-matches by sorting candidate ComponentDefinition names and picking the last entry (controllers/apps/cluster/transformer_cluster_normalization.go:662-698, selection at :694, main @ aa7f8c8). Zero matches produce a hard error, but multiple matches produce no warning, condition, or event — the selection is invisible unless the user diffs the generated Component's resolved compDef against expectation.

Why it matters

Name-sort selection means an addon chart that ships a new ComponentDefinition (e.g. acmedb-storage-1.10.0 sorting after acmedb-storage-1.9.0) can silently change which definition existing patterns resolve to. Combined with prefix/regex patterns recommended for version management, drift is easy to introduce and hard to notice — today's mitigation is chart unit tests asserting name closure, which not every addon has.

Suggested fix

When a pattern matches more than one ComponentDefinition, surface the resolved choice and the candidate count as an event or condition on the Cluster/Component (e.g. "pattern ^acmedb-storage-.* matched 3 ComponentDefinitions, selected acmedb-storage-1.10.0"). This keeps current semantics but makes the tie-break observable and auditable.

[weicao]

Implementation evaluation (offering to implement once the shape is agreed):

All call sites go through resolveCompDefinitionNServiceVersion in controllers/apps/cluster/transformer_cluster_normalization.go, and clusterTransformContext reaches an EventRecorder, so plumbing is straightforward. The real question is signal-vs-noise:

• Prefix/regex compDef patterns are the recommended versioning practice, so "pattern matched >1 CMPD" fires for most addons on every reconcile — too noisy even as a Normal event.
• The meaningful trigger is narrower: after serviceVersion filtering, more than one compatible ComponentDefinition remains and the name-sort tie-break decides (len(compatibleCompDefNames) > 1 at transformer_cluster_normalization.go:693). That is the genuinely ambiguous case this issue is about.

Proposal: emit a Normal event on the Cluster (deduped by recorder aggregation) only in that narrow case, message like resolved componentDef acmedb-storage-1.10.0 for component storage (3 candidates matched pattern ^acmedb-storage-.* with serviceVersion 1.0.0). Alternative: a condition on the generated Component instead of an event, which survives longer for audit.

Happy to send a PR for either shape — maintainers pick event vs condition.