TridentConfigurator CRD has persistent diff

[lindhe]

Describe the bug

I just upgraded from Helm chart version 100.2402.0 to 100.2406.1. After the upgrade, I noticed that Argo CD still had a diff between desired state and live state, and it never goes away:

In the new CRD TridentConfigurator, there is a list additionalPrinterColumns where objects may set the field priority. Some elements in the list has priority: 0 according to the CRD applied by the Helm chart:

trident/helm/trident-operator/crds/tridentconfigurators.yaml

Lines 17 to 42 in 722e7ef

	additionalPrinterColumns:
	- name: Phase
	type: string
	description: The backend config phase
	priority: 0
	jsonPath: .status.phase
	- name: Status
	type: string
	description: The result of the last operation
	priority: 0
	jsonPath: .status.lastOperationStatus
	- name: Cloud Provider
	type: string
	description: The name of cloud provider
	priority: 0
	jsonPath: .status.cloudProvider
	- name: Storage Driver
	type: string
	description: The storage driver type
	priority: 1
	jsonPath: .spec.storageDriverName
	- name: Deletion Policy
	type: string
	description: The deletion policy
	priority: 1
	jsonPath: .status.deletionPolicy

It seems like they get modified, I'm guessing by the Trident operator, so the priority field gets removed if its value is 0. This causes a constant diff in tools like Argo CD. In the particular case of Argo CD, it is possible to ignore changes to certain object attributes, but I think this diff is probably unintentional and should be fixed.

Environment
Provide accurate information about the environment to help us reproduce the issue.

• Trident version: 24.06.1
• Trident installation flags used: helm template --include-crds trident -n trident trident/trident-operator --set 'tridentLogFormat=json' --version 100.2406.1 (this is similar to what Argo CD with Kustomize executes in my case)
• Container runtime: containerd
• Kubernetes version: 1.28.11
• Kubernetes orchestrator: Rancher v2.8.5
• Kubernetes enabled feature gates: default for RKE2.
• OS: RHEL 9.2
• NetApp backend types: ONTAP NAS
• Other: null

To Reproduce

1. Install the Helm chart version 100.2406.1
2. kubectl get crd TridentConfigurator -o yaml and see that priority: 0 is unset.

Expected behavior

There should be no diff after apply.

Additional context

If I sync Argo CD so the priority field gets set, the trident-operator produces this log: trident-operator.log

[hrivera-ntap]

Seeing the same with my argo deployment of trident-operator. I suspect k8s considers priority 0 as redundant and mutates it out.

Current workaround with ArgoCD is to utilize the ignoreDifferences feature of the Application: (https://argo-cd.readthedocs.io/en/stable/user-guide/diffing/)

[miminar]

We've just bumped into this as well. In case someone finds it useful, here's our change to Application/trident to address this:

--- all.yaml	2024-08-06 10:11:43.216415082 +0200
+++ all.new.yaml	2024-08-06 10:09:10.890141528 +0200
@@ -855,22 +855,29 @@
     helm:
       valueFiles:
         - values.yaml
         - values.eu-dev.yaml

   destination:
     server: "https://kubernetes.default.svc"
     namespace: trident
+  ignoreDifferences:
+    - group: apiextensions.k8s.io
+      jqPathExpressions:
+      - .spec.versions[]? | .additionalPrinterColumns[]? | .priority
+      kind: CustomResourceDefinition
+      name: tridentconfigurators.trident.netapp.io
   syncPolicy:
     automated:
       selfHeal: true
       prune: true
     syncOptions:
       - CreateNamespace=true
+      - RespectIgnoreDifferences=true
     retry:
       limit: 10000000
       backoff:
         # the amount to back off. Default unit is seconds,
         # but could also be a duration (e.g. "2m", "1h")
         duration: 30s
         # a factor to multiply the base duration after each failed retry
         factor: 2