How to ignore PV's that are created by an operator?

[CoreyLylyk]

I have deployed TiDB Operator, and when I create a cluster, the PV's associated with the services show as

OutOfSync (This resource is not present in the application's source. It will be deleted from Kubernetes if the prune option is enabled during sync.)

I have the following in the application config:

  ignoreDifferences:
    - kind: PersistentVolume
      jsonPointers:
        - /spec/claimRef
        - /metadata
        - /status

What am I missing?

[tuusberg]

You need to use https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#resource-exclusioninclusion in order to achieve that. I was facing the same issue and the above solution fixed it for me. Hope it helps!

[CoreyLylyk]

Perfect thank you!

I used a patch file to fix my issue for TiDB application that was having the issue

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
data:
  resource.exclusions: |
    - apiGroups:
      - "*"
      kinds:
      - PersistentVolume
      clusters:
      - "*"
      namespaces:
      - "tidb"
      ```
      
Hope this can help someone also

[AurimasNav]

does not seem like specifying namespaces are supported for resource.exclusions

[winterrobert]

@tuusberg what's the solution if I want to ignore not all PVs or PVCs but rather a specific PVC?

I've tried all combinations of ignoreDifferences, with or without jqPathExpressions, but ignoreDifferences only seems to react to changes within a specific resource and doesn't ignore the whole resource right?

  ignoreDifferences:
  - kind: PersistentVolumeClaim
    # group: "" # This is the same as the core group
    # name: nameofmyresource
    # namespace: thenamespaceoftheresource
    jqPathExpressions:
    - .

My understanding:

• If I want to ignore all resources of a specific Kind: Resource Exclusion
• If I want to ignore changes to properties of a resource: ignoreDifferences
• If I want to ignore syncing a specific resource: ?

[ChristianCiach]

Doesn't seem to be possible at the moment. We would need to #3415 to be supported.