storage-provioners/netapp components missing unique name

[hiteshmathur19]

We are deploying Trident in an airgap system. So we package the needed trident containers in our local registry (running inside the k8s cluster)

During installation, we give the registry url in the TridentOrchestator object.

cp1:~> kubectl get tridentorchestrators.trident.netapp.io trident -o yaml | grep -i image
autosupportImage: registry.local:5000/trident-autosupport:25.06-2da0d1b1
imagePullPolicy: IfNotPresent
imageRegistry: registry.local:5000
tridentImage: registry.local:5000/trident:25.06.0-2da0d1b1

The rest of the csi containers are pulled from this registry, whose versions are hardcoded in the trident code.

https://github.com/NetApp/trident/blob/master/config/config.go#:~:text=config.go

      // KubernetesCSISidecarRegistry is where the CSI sidecar images are hosted
      KubernetesCSISidecarRegistry = "registry.k8s.io/sig-storage"
      CSISidecarProvisionerImageTag = "csi-provisioner:v5.3.0"
      CSISidecarAttacherImageTag = "csi-attacher:v4.10.0"
      CSISidecarResizerImageTag = "csi-resizer:v1.14.0"
      CSISidecarSnapshotterImageTag = "csi-snapshotter:v8.3.0"
      CSISidecarNodeDriverRegistrarImageTag = "csi-node-driver-registrar:v2.15.0"
      CSISidecarLivenessProbeImageTag = "livenessprobe:v2.15.0”

These containers versions are hardcoded. Our product release cycle contains multiple major and patch releases that are going on in parallel, and we do the CVE corrections in above containers frequently. Since the versions are hardcoded in trident code, we cannot use unique names when we rebuild these containers, This creates frequent overwrites problem in our registry. There is no way to track which container was built for which release cycle and so on.
NetApp Support Case for this : 2010559854

[clintonk]

Hello, @hiteshmathur19. You can perform this level of customization with the custom YAML feature of tridentctl install. Would that work for you? Otherwise, what if we built a custom YAML mechanism for the operator? In any case, please understand that we pin the sidecar versions since those are what we test. We update Trident's sidecar and 3rd-party dependencies every major release in part to address any CVEs to which Trident might be vulnerable.