Feat | Connect directly to argo-server and repo-server instead of port-forwarding - #461
Feat | Connect directly to argo-server and repo-server instead of port-forwarding#461twiechert wants to merge 2 commits into
Conversation
|
Thanks for the PR. I like the direction here! We should try to avoid port-forwarding when we can, but without making the code too complicated. I wonder if we can avoid adding a user-facing and then construct something like: I vibe coded a quick example implementation of this here, feel free to steal from it: 🚀 No pressure to use it exactly as-is, but I think the general approach would make the in-cluster case work automatically while keeping the CLI simpler for users. What do you think? Let me know if you have any use cases for |
|
Sounds good to me. Let us stick with the auto-detect option :) |
|
@twiechert Cool, Do you want to update you PR? or should i create a new one? :) |
Mirrors the repo server lookup for the API server, so the server-api / repo-server-api render methods stop port-forwarding in cluster too. Same label convention (part-of=argocd, component=server), same fallback: outside the cluster nothing changes. The scheme has to be probed rather than read off the Service. argocd-server speaks TLS unless started with --insecure, and the chart maps both the http and the https Service port to the same container port either way, so the port name says nothing about the actual protocol. Guessing wrong is expensive: plain HTTP against a TLS listener blocks until the client timeout rather than failing fast. One probe against /api/version settles it.
cf60961 to
1357a0b
Compare
dag-andersen
changed the title
| _ = resp.Body.Close() | ||
| return url, nil | ||
| } | ||
| return "", fmt.Errorf("Argo CD server at %s answered neither https nor http: %w", address, lastErr) |
There was a problem hiding this comment.
| return "", fmt.Errorf("Argo CD server at %s answered neither https nor http: %w", address, lastErr) | |
| return "", fmt.Errorf("argo CD server at %s answered neither https nor http: %w", address, lastErr) |
dag-andersen
left a comment
dag-andersen
left a comment
There was a problem hiding this comment.
Hi @twiechert! With the introduction of Argo CD 3.5, connecting directly to the server may break the tool for some users because the Argo CD Helm chart now includes NetworkPolicies that block the traffic. We need to handle this. I am thinking we should either default back to port forwarding or provide a clear warning to users so they can fix it.
2 participants
Adds
--repo-server-addressfor--render-method=repo-server-api: when set, the tool dials the repo server at thathost:port(e.g.argocd-repo-server.argocd.svc:8081) via the existing-but-unwiredNewClientWithAddress, and skipsEnsurePortForward. Empty (default) = unchanged port-forward behavior, so it's backward compatible.Motivation: running the tool in-cluster and connecting to the repo-server Service directly (kube-proxy load-balanced, survives pod churn) instead of a single-pod port-forward.