fix(cdi): omit the CDI clone strategy override when unset - #4138

What this PR does

cdi-cr.yaml rendered cloneStrategyOverride unconditionally, so there was no way to let CDI pick a clone strategy per StorageProfile. The CRD enum is copy/snapshot/csi-clone with no empty member, so neither obvious workaround got there: an empty value rendered cloneStrategyOverride: "", which that enum does not accept, and a null one rendered a bare key. Both checked against main with helm template rather than assumed.

Now the key is guarded on a non-empty value, same as uploadProxyURLOverride just below it in the same file. With the field absent, CDI reads the target StorageClass's StorageProfile and uses its clone strategy.

Default stays csi-clone. Rendered at the default and diffed against main, the output is byte-identical, so nothing already deployed moves.

Tests

tests/clone_strategy_test.yaml pins both directions: absent when the value is empty, absent when it is null, csi-clone on the chart default, snapshot through unchanged. It sits alongside the existing importer-resources and standalone_render_test suites, with its own file and suite name and no shared test names; make test runs all three.

I checked the suite can fail rather than assuming it works. Reverting the guard reddens the two absent-field cases, deleting the field outright reddens the default and passthrough cases, hardcoding the value reddens the passthrough case, and rendering a bare key reddens all four. The two sibling suites stay green through every one of those, so the reds are attributable to this suite.

The null case is pinned as an input rather than argued from with treating null and empty alike. It cannot pass vacuously: flipping its assertion to expect the default returns unknown path, not a csi-clone mismatch, which is what shows the null actually reaches the template instead of the assertion passing on a value that never arrived.

Known gaps

copy is accepted by the enum but no test drives it, so the suite does not pin that it reaches the CR. Concretely: wrapping the guard in {{- if ne . "copy" }}, which silently drops that one strategy, still passes all nine tests. Named here rather than fixed so the boundary is visible to the next reader instead of being rediscovered.

Scope

Context: #2908. This is the first of the three directions that issue lists, so it does not close it and carries no Closes. The default is deliberately left at csi-clone, since whether that is the right default is the second direction and a separate decision. The third, vm-disk warning on a cross-StorageClass request, is untouched. An operator who has not set cloneStrategyOverride: "" sees the reported symptom exactly as before.

Screenshots

Not a UI change.

Downstream repositories

Walked the trigger map against the diff. It is one guarded key in a packages/system chart, a values comment, and a test suite: no package added or renamed, no values.schema.json (this chart has none), no ApplicationDefinition, no namespace, nothing under hack/, no platform values key. The ccp entry covers hack/package.mk and make-target behaviour, and this touches neither. Nothing in the map reaches it.

• No downstream repository is affected by this change
• cozystack/website - follow-up:
• cozystack/terraform-provider-cozystack - follow-up:
• cozystack/ansible-cozystack - follow-up:
• cozystack/ccp - follow-up:
• cozystack/talm - follow-up:
• cozystack/cozyhr - follow-up:
• cozystack/cozy-proxy - follow-up:
• cozystack/cozystack-telemetry-server - follow-up:
• cozystack/external-apps-example - follow-up:
• cozystack/examples - follow-up:
• cozystack/community - follow-up:

Release note

fix(cdi): `cloneStrategyOverride` in the `kubevirt-cdi` package can now be left empty, which omits the field and lets CDI pick a clone strategy per StorageProfile. The default is unchanged at `csi-clone`.