no diff detected after manual configmap changes

[KlavsKlavsen]

I have installed yetibot helm chart, using argocd, and I have edited the configmap by hand - and argocd shows all in sync (green).

If I view the configmap in argocd - it shows me this for live:

apiVersion: v1
data:
  YB_DB_URL: 'jdbc:postgresql://yetibot:yetibot@yetibot-postgresql:5432/yetibot'
  YB_LOG_LEVEL: debug
  YB_LOG_ROLLING_ENABLED: 'false'
  YB_URL: 'http://localhost:3003'
  YETIBOT_ENV_PREFIX: yb
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: >
      {"apiVersion":"v1","data":{"YB_DB_URL":"jdbc:postgresql://yetibot:yetibot@yetibot-postgresql:5432/yetibot","YB_LOG_ROLLING_ENABLED":"false","YB_URL":"http://localhost:3003","YETIBOT_ENV_PREFIX":"yb"},"kind":"ConfigMap","metadata":{"annotations":{},"labels":{"app":"yetibot","app.kubernetes.io/instance":"yetibot","app.kubernetes.io/managed-by":"Helm","app.kubernetes.io/name":"yetibot","app.kubernetes.io/version":"20210514.195820.4e186db","argocd.argoproj.io/instance":"yetibot","helm.sh/chart":"yetibot-1.0.56"},"name":"yetibot","namespace":"yetibot"}}
  creationTimestamp: '2021-04-27T16:21:51Z'
  labels:
    app: yetibot
    app.kubernetes.io/instance: yetibot
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: yetibot
    app.kubernetes.io/version: 20210514.195820.4e186db
    argocd.argoproj.io/instance: yetibot
    helm.sh/chart: yetibot-1.0.56
  managedFields:
    - apiVersion: v1
      fieldsType: FieldsV1
      fieldsV1:
        'f:data':
          .: {}
          'f:YB_DB_URL': {}
          'f:YB_LOG_ROLLING_ENABLED': {}
        'f:metadata':
          'f:annotations':
            .: {}
            'f:kubectl.kubernetes.io/last-applied-configuration': {}
          'f:labels':
            .: {}
            'f:app': {}
            'f:app.kubernetes.io/instance': {}
            'f:app.kubernetes.io/managed-by': {}
            'f:app.kubernetes.io/name': {}
            'f:app.kubernetes.io/version': {}
            'f:argocd.argoproj.io/instance': {}
            'f:helm.sh/chart': {}
      manager: argocd-application-controller
      operation: Update
      time: '2021-05-20T08:18:46Z'
    - apiVersion: v1
      fieldsType: FieldsV1
      fieldsV1:
        'f:data':
          'f:YB_LOG_LEVEL': {}
          'f:YB_URL': {}
          'f:YETIBOT_ENV_PREFIX': {}
      manager: kubectl-edit
      operation: Update
      time: '2021-05-20T09:01:48Z'
  name: yetibot
  namespace: yetibot
  resourceVersion: '22349480'
  uid: 5a282318-2f7b-4dfd-b157-f4a456506ab8

and this for desired.. and yet the "diff" tab is empty ?

apiVersion: v1
data:
  YB_DB_URL: 'jdbc:postgresql://yetibot:yetibot@yetibot-postgresql:5432/yetibot'
  YB_LOG_ROLLING_ENABLED: 'false'
  YB_URL: 'http://localhost:3003'
  YETIBOT_ENV_PREFIX: yb
kind: ConfigMap
metadata:
  labels:
    app: yetibot
    app.kubernetes.io/instance: yetibot
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: yetibot
    app.kubernetes.io/version: 20210514.195820.4e186db
    argocd.argoproj.io/instance: yetibot
    helm.sh/chart: yetibot-1.0.56
  name: yetibot
  namespace: yetibot

I would have expected it to say "out-of-sync" since I clearly edited data section ?

[KlavsKlavsen]

It seems to be caused by the upstream (an OCI endpoint) not being available.. When I tried deleting the configmap and then doing hard refresh.. it complained it could not fetch the helm chart.. and after that got sorted - it now shows correct diff.. So There SHOULD have been an error shown.. It MAY be only relevant to OCI backends.. but it'll probably also apply to a normal helm repo backend not being correct.. a test could be to simply point to a none-existing version of the chart (after existing install is green).. and see if it fails clearly or not

[alexmt]

hello @KlavsKlavsen , this is actually expected behavior. Argo CD uses the same diffing logic and kubectl diff: it takes into account only those field that applied using kubectl apply. So if you manually add new field to data then it is not considered as a deviation.

[KlavsKlavsen]

So ArgoCD can't really be used for configuration management (like puppet and others can) - where you ALSO use it to detect if "managed resources have been changed in production" ? Then IMHO this should be a feature request issue.. thats a pretty big usecase, I was expecting to be able to use ArgoCd to detect manual changes to our environment (as those are potentially VERY DANGEROUS) - as they break our recovery plan (which is to reinstall with argocd - using code in git - ie. the gitops way).

[alexmt]

Argo CD follows the Kubernetes declarative management approach. It petty much automates kubectl apply/diff commands. I agree it is not perfect but there is not much we can do to improve it.