[STAC-25666] Agent chart: integration overlays override user values, making objects.pods unconfigurable with SUSE Virtualization enabled

[kkaempf]

STAC-25666

Integration overlays in the suse-observability-agent chart override explicit user values, which makes otel.k8sResourceCollector.objects.pods impossible to configure while the SUSE Virtualization integration is enabled.

Steps to reproduce

helm template stable/suse-observability-agent with otel.enabled=true and:

values	rendered pods watch
{{objects.pods: {group: ""} }}, suseVirtualization default (true)	label_selector: "kubevirt.io=virt-launcher"
{{objects.pods: {group: "", labelSelector: ""} }}, suseVirtualization true	label_selector: "kubevirt.io=virt-launcher" — user override ignored
{{objects.pods: {group: ""} }}, suseVirtualization: false	no selector (correct)

Expected

An explicitly set labelSelector in user values should win over an integration overlay, or at minimum it should be possible to clear it.

Root cause

templates/_helpers.tpl:429, in stackstate-k8s-agent.k8sResourceCollector.mergedValues:

{{- $vals = mustMergeOverwrite $vals $overlayVals }}

The overlay is merged over the user's values, so the overlay always wins. The overlay in question is integrations/suse-virtualization.yaml:17-19, enabled by default at values.yaml:721.

Impact

objects is a map keyed by resource name, so there can only be one pods watch. Combined with the merge direction, that means full pod collection and the SUSE Virtualization integration are mutually exclusive today. Any user who wants broad pod topology must disable KubeVirt support, and vice versa.

Found while starting STAC-25661 Ready to work on (cluster-agent to OTel), where a pods watch is required — but this affects any user of both features, independent of that effort.

Suggested fixes

1. Reverse the merge for explicitly-set user values so overlays supply defaults rather than overrides.
2. And/or allow multiple watches per resource type, so a KubeVirt-scoped pods watch and a cluster-wide pods watch can coexist. Requires a key other than the bare resource name.

Related: the KubeVirt mappings already filter by kind and API group in their CEL condition, so a cluster-wide pods watch is a superset of what the integration needs — filtering could move into the mapping instead of the watch. Needs agreement from the SUSE Virtualization stackpack owner.