Sync vs Refresh

[Mais316]

Is there a clear description of sync action vs refresh vs hard refresh?

[chetan-rns]

Hi @Mais316,

Sync: Reconciles the current cluster state with the target state in git.

Refresh: Fetches the latest manifests from git and compares diff.

Hard Refresh: Argo CD caches the manifests and a hard refresh will invalidate this cache.

The descriptions for these concepts can be found here https://argo-cd.readthedocs.io/en/stable/core_concepts/

IMO we should add a tooltip for these buttons in the Argo CD UI with a brief description of these concepts.

[emirot]

When I clicked refresh it is also doing a sync, is that because of some other configuration?
I was expecting to just tell me you are out of sync.

[jannfis]

@emirot You probably have auto-sync enabled, which makes Argo CD start a sync whenever it detects a difference between live and desired state.

[MarcoJanecki]

By now, a click on "Sync" also does a refresh. With this functionality, I don't see why Refresh and the "Sync status" is not obsolete. Any thoughts to this are appreciated. :)

[thiagowfx]

With this functionality, I don't see why Refresh and the "Sync status" is not obsolete. Any thoughts to this are appreciated. :)

In my experimentation I reached the same conclusion.

[david-polak-ataccama]

With this functionality, I don't see why Refresh and the "Sync status" is not obsolete. Any thoughts to this are appreciated. :)

In my experimentation I reached the same conclusion.

Going from an empty git source you can't use sync since there's nothing to sync. You need to fetch the new state using refresh first.

[dlemfh]

Hey @chetan-rns and community,

I'm still not sure I understand exactly where refresh and hard-refresh differ..

Would you mind elaborating a bit further,
or could you point me to a more detailed document I can look into?

Thanks!

[Davidonium]

I am not a maintainer so what I'm writing here might not be 100% accurate so I am open to be corrected.

ArgoCD keeps several caches to avoid scaling issues. The ones involved in the regular and hard refreshes are two, the revision cache and the manifest cache.

The revision cache stores all the git refs retrieved by a git ls-remote that is done in the argocd-repo-server, the key is the repo name (see here). That way, each time a sync is done the git ls-remote can be skipped, as it can overload the target git server and depending on the repository it can be slow. This is done by argo-cd to know exactly which git commit sha is your app's revision pointing to so that the following checkout is deterministic. The default value for this cache is 3m.

See the example output of ls-remote for argoproj/argo-cd here.

$ git ls-remote
From git@github.com:argoproj/argo-cd.git
cfb24701d2711fdce7e1c22e6207003b06568abf	HEAD
6649617c52b3e1111f951f5e4b3bf1eac670f958	refs/heads/alexec-patch-1
b80f8cdca80db10f1624936080702c71cb5feaaa	refs/heads/gh-pages
ec77e6105b30e3ac9b60dca62d67ac41b790cc03	refs/heads/ibb-docs
cfb24701d2711fdce7e1c22e6207003b06568abf	refs/heads/master
7b654cbd754ee5ad1c3e5c5a4107f0ab0e77739f	refs/heads/parameterized-cmps-tests

The manifest cache stores the kubernetes manifests generated by the source you've set in your application. For example, for a helm based application, the manifests are stored in this cache after checking the git repository at the git commit sha from your app's revision and running helm template. The key used for this cache contains the git commit hash (which could come from the above mentioned cache, see revision retrieval and the key generation). It's default duration is 24h.

Now that the knowledge on the cache is there, what remains is knowing that the regular refresh forces a lookup to the git refs and the hard refresh triggers both a lookup to the git refs and a lookup to the manifests source (git). If you support a big argocd installation it's important to avoid doing refreshes when not needed.

[Swaps76]

thank you @Davidonium , knowing about the two caches is the foundation for understanding the very confusing 'sync status', 'last sync' terminology in the UI. Just curious then, why is the manifest cache not cycled every 3m like the revision cache? Does a sync effectively do a hard refresh and then apply the new manifests in the manifest cache?
Also does a hard refresh also do a refresh first?