Open alionski opened 1 year ago
Happening here too in v2.6.0. (argocd: v2.6.0+acc554f)
We use this command:
/usr/local/bin/argocd --server **** --grpc-web --auth-token **** app get --refresh --show-operation <appname>
and got:
time="2023-02-14T18:50:47Z" level=fatal msg="rpc error: code = Unavailable desc = closing transport due to: connection error: desc = \"error reading from server: EOF\", received prior goaway: code: ENHANCE_YOUR_CALM, debug data: \"too_many_pings\""
I'm having this problem as well. I tried it on v2.5.6 of argocd and earlier versions. Still no dice.
i am having the same issue as well with the latest version of argocd cli
Also have this issue, any solution?
I'm having the same issue as well. This has been happening for a few versions already.
We are currently on v2.6.7
FYI we upgraded our server to the latest version v2.7.8 and the noticed argocd app sync
CLI was significantly faster compared to before.
The same sync previous took 10+ minutes was reduced to under 2 minutes.
Fixed by #15708 I believe
Still broken :( My workaround:
kubectl wait --for=jsonpath='{.status.sync.status}'=Synced -n argocd applications.argoproj.io/kuvaq --timeout 300s
kubectl wait --for=jsonpath='{.status.sync.revision}'=commit-hash-here -n argocd applications.argoproj.io/kuvaq --timeout 300s
kubectl wait --for=jsonpath='{.status.operationState.phase}'=Succeeded -n argocd applications.argoproj.io/kuvaq --timeout 300s
kubectl wait --for=jsonpath='{.status.health.status}'=Healthy -n argocd applications.argoproj.io/kuvaq --timeout 300s
Suuuuuper slow
argocd: v2.11.0+unknown
BuildDate: 2024-05-08T06:39:46Z
GitCommit:
GitTreeState:
GitTag: 2.11.0
GoVersion: go1.22.2
Compiler: gc
Platform: linux/amd64
Checklist:
argocd version
.Describe the bug
This issue is very similar to the other one from me https://github.com/argoproj/argo-cd/issues/12211 and is related to https://github.com/argoproj/argo-cd/issues/7284 and https://github.com/argoproj/argo-cd/issues/8910
When syncing an application via the cli with
argocd app sync
, the status reported by the cli lags behind the updates in the application CR and the last updates in the CR seem to be missed by the cli client or the server never sends them. Adding the--grpc-web
flag makes no difference.I was looking into why the cli is so slow in our CI when there are no updates to the application and thus no syncing is needed (last time it took over 1hr). The
argocd app sync
command basically hangs until the timeout is reached. To figure out what the client was seeing vs what was happening in the cluster, I added the following (quite aggressive and chatty) logs to the the cli client frommaster
:Then I started watching the application CR, deleted ConfigMap
redacted-cm-name
that belongs to it and executedargocd app sync
. Output of the watch:and the output of
argocd app sync
from cli client frommaster
with my logs (prepended with----------------
):As you can see, the sync finished very quickly and
Operation
disappears from the CR at2023-01-30T13:10:14Z
(note that the time in logs is CET, not Zulu), but the cli was getting messages with a delay, the last message the client received still containedOperation
, and it never got a message that the application reached the desired state (I assume it has to be an event of typeDELETED
since theOperation
is gone from the CR). The result is thatsync
hangs until the timeout is reached instead of exiting once the app is synced and happy. At the same time, the UI followed the changes in the CR without a delay and was showing the correct status.To Reproduce
Create an application that has resources that take a very short time to create/sync, e.g. a ConfigMap. Sync the application and wait for it to be synced and healthy. Delete the ConfigMap in the cluster and wait for the app to switch to the OutOfSync state. Execute
argocd app sync
and compare the sync status reported by the UI and the cli and also watch the application CR in the cluster.Expected behavior
argocd app sync
takes the same time to sync as syncing from the UI and doesn't lose gRPC events.Screenshots
N/A
Version
Logs
See above. I didn't find anything helpful in the server logs.