CSI Driver gets Installed contradicting Documentation

[tom-ludwig]

Expected Behavior

The default helm values, list kubeletVolumePluginPath under installation.kubeletVolumePluginPath.

If I don't touch the helm values I'd expect the default values of None.

I expect that after the installation kubeletVolumePluginPath(in the crd) will be None as well.

Even if it is set to None (default value) it will install the csi.

Current Behavior

The csi driver get installed if you set installation.kubeletVolumePluginPath` to "None".
The CSI driver gets installed even if you don't touch the default values.

If you set kubeletVolumePluginPath: "None" it will not install: i.e. installation.kubeletVolumePluginPath

Possible Solution

Adjust documentation and helm default values or source code.

Steps to Reproduce (for bugs)

Install the operator via helm without touching the values.yaml

Your Environment

Helm chart version: 3.31.2

References

Default values.yaml:

  # Disable CSI driver by default.
  kubeletVolumePluginPath: "None"

https://github.com/projectcalico/calico/pull/10400/files
#7569
#8335

https://github.com/tigera/operator/blob/d124be09e418c7e4d8a1ff918e89d6f60eb9f13a/api/v1/installation_types.go#L136

TL;DR

1. The source code says CSI will be enabled by default. Documentation says otherwise.
2. kubeletVolumePluginPath is NOT under installation

[caseydavenport]

Yeah, this is definitely annoying and we should fix it. Hopefully a quick change to our helm chart?

[tom-ludwig]

I took another look into the source code over the weekend, and I believe I found the culprit. It looks like a breaking change in the template logic from a few versions back.

Previously, the template included a line to map the root value:

{{- $_ := set $installSpec "kubeletVolumePluginPath" .Values.kubeletVolumePluginPath }}

That line was removed. While I understand cleaning up the template, it might have been better to include a conditional check there to safeguard against old configurations still lingering at the root level.

In any case, I would like to submit a PR to improve the comments in values.yaml. I think adding a few explicit pointers there will help guide users to the right structure and prevent this confusion in the future. Is that ok with you?

[caseydavenport]

Sounds good to me, thank you @tom-ludwig !