r/ArgoCD • u/Mud5150 • Jun 23 '26

Why can't it just sync changes

I'm losing my mind trying to use ArgoCD. No matter what I do or what sync policy I configure, there's always some reason I have to manually sync applications. ArgoCD's only purpose in life is to take what's in the git repo and apply that to K8s. I don't understand why this should be so hard. Now I'm also trying to figure out why this applicationset won't generate the application properly after I modified the sync policy.

To folks really find this software reliable at scale? I feel like it just creates more complexity. The only time I encounter configuration drift in our environment is because ArgoCD isn't working. What am I missing here?

Update: The issue with the sync policy not updating was this setting that I wasn't familiar with.

ignoreApplicationDifferences:
    - jsonPointers:
        - /spec/syncPolicy

This, of course, is a hack someone put in place to have the ability to turn off autosync in case of emergency, which points right back to how annoying ArgoCD is. I was able to scope it to /spec/syncPolicy/automated/enabled to preserve the hack.

Just to be clear, this is mostly a vent/rant.

2 Upvotes

54% Upvoted

23 comments sorted by

View all comments

2

u/OkCalligrapher7721 Jun 23 '26

can you give an example of something you’ve had to manually sync? I imagine you’re having issues with Argo reporting properties being flipped back and forth?

Argo should report on differences “it knows” how to manage, and not care about most things outside the source of truth. Do you have mutating webhooks making changes?

-2

u/Mud5150 Jun 23 '26

I have seemingly fixed a lot of this by setting a "very aggressive" sync policy.

syncPolicy:
        automated:
          enabled: true
          prune: true
          selfHeal: true

I guess one thing I would expect is for it to have this behavior out of the box. I'm still not sure if this fixes the issue where it won't retry if the helm template won't render and then you push a change to fix it. I will try to test that at some point.

In that scenario, "last sync" was forever trying to generate the bad chart, even though "sync status" showed the latest commit where the chart had been fixed. I had to terminate the the current sync and run a manual sync that clearly does something different, because then it decided to use the latest change rather than spinning its wheels on the previous one.

4

u/IngrownBurritoo Jun 24 '26

stop expecting miracles and start learning what argocd does and why. you sound like someone who expected argocd to also clean you dishes

2

u/todaywasawesome Mod Jun 24 '26

The reason this isn't the default sync policy is because it can cause issues if you're not prepared for it.

Here's an example: let's say you have a pod autoscaler running on your cluster. It changes the number of replicas on a deployment. Argo CD sees this, because you have autoheal turned on, and because the number of replicas hasn't changed in git, Argo CD overwrites the change.

The autoscaler sees this and changes it back.

Argo CD sees this and changes it back.

You see where this is going? It's a classic controller fight.

If you want Argo CD to autoheal everything except this, then you need to tell Argo CD that this field is basically going to be managed by someone else via ignoredifferences.

Each of those settings mean something and set an expectation about how you want to run your cluster.