Manage Argo CD Using Argo CD Reconciliation loop #1533
Comments
|
I can't find why it is happening. And thus cannot use that feature, which is quite sad, since it is actually the most important feature and why i use argocd |
|
We had the same issue when trying to have an ArgoCD application manage all application including the aforementioned application.
|
|
After some discussion, we're not sure if this is a feature of a bug. Certainly, people have Argo CD self-manage, but due to how the plumbing now works inside it, this will result in a reconciliation loop. There's no simple fix to this AFAIK. This workaround is to manage Argo CD outside of itself, be that manually or with another Argo CD instance. |
|
There's a fix. It is just not trivial :) |
|
Trying to find simple way to improve it. |
|
Looks like it is broken again. See #1547 (comment) |
|
Hello @KarstenSiemer , finally got back to this issue, but unfortunately cannot reproduce it. Implemented e2e test which creates self-referenced app and makes sure there is not reconciliation loop: #1724 PR deploys app which is pointing to itself. Can you please check if I'm missing something? |
|
Nope, i have to reopen. hence the green line being twice the amount of the red one it feels less bad then before but definitely destroys argo-cd in a way of having the two apps extremely busy so that nothing gets rolled out any more |
He is correct, if the self reconciling app isn't being pulled by the seeding application, then there is no reconciliation loop. The last thing that is a problem with seeding applications is the heredity of application state and that argocd doesn't do another reconciliation as long as an app is in progressing state. When a seeded application becomes progressing, the seeder will be in progressing state, too. |
|
some app use configmap map as leader-election helper, like cert-manager, nginx-ingress, this will trigger ArgoCD reconciliations, those configmap usually are un-managed resources. |
alexmt
added
component:application-sets
|
Hello, We're hit by this issue too. We have app of apps (with the root of them managing itself), an app which manages Argo CD, and apps with leader election config maps or lock config maps. That is, we collection all the pattern which seem to lead to high reconciliation rate and CPU usage (Argo CD uses a full CPU)! |
|
This bug is quite old, since then there was an improvement that prevented unnecessary update of |
|
This is still happening to use in ArgoCD |
|
Hello! Br, Alexey |
Describe the bug
Apparently i've somehow build a reconciliation loop by managing argocd using argocd.
As it can be seen here, the controller constantly requests a refresh of the argo-cd application.
Even though it is already healthy and in sync. The auto sync feature isn't even on.
Screenshots
The argo-cd application is owned by the system-cicd appproject.
The argocd-apps application is owned by argocd-objects appproject and used to create applications that are lying inside git.
The argocd-projects application is also owned by argocd-objects and used to create appprojects that are lying inside git.
I do not see any reason why it would be in a loop.
Here you can see, that it is trying to reconcile very often:
I am also unsure what
can not retrieve list of objects using index : Index with name namespace does not existmeans.Since argo-cd works wonderfully on all applications that i've passed to it.
Versions:
argo-cd: v1.0.0rc0
kubernetes: v1.14.1
I am having this problem for a few releases now. I am not sure when it started, but in version
v0.10.3this was working just fineThe text was updated successfully, but these errors were encountered: