Describe the bug
I run Argo CD behind a proxy server, and set HTTP(S)_PROXY and NO_PROXY environment variables for its components.
If I set envs for argocd-repo-server but not for argocd-server, then argocd app sync APP fails while trying to connect to the Git repository directly.
The source of connection trials is the pod of argocd-server.
This behavior seems to go against the division of roles shown in the architectural overview.
In my understanding, only argocd-repo-server communicates with the Git repository, and argocd-server should ask argocd-repo-server for Git information.
This does not happen for applications with target revisions of pinned commit SHAs.
I suppose that resolveRevision() in argocd-server causes this.
To Reproduce
Steps to reproduce the behavior:
argocd-repo-server,argocd-application-controller,argocd-metrics,argocd-server,argocd-server-metrics,argocd-redis,10.0.0.0/8, where 10.0.0.0/8 is for k8s API serverargocd app sync APP for an application with a target revision of branch/symbol/tagExpected behavior
argocd app sync APP succeeds by setting HTTP(S)_PROXY only for argocd-repo-server.
Screenshots
N/A
Version
argocd: v1.0.1+5fe1447.dirty
BuildDate: 2019-05-28T17:26:35Z
GitCommit: 5fe1447b722716649143c63f9fc054886d5b111c
GitTreeState: dirty
GoVersion: go1.11.4
Compiler: gc
Platform: linux/amd64
argocd-server: v1.1.0-rc1+unknown
BuildDate: 2019-06-17T05:01:36Z
GitCommit:
GitTreeState: clean
GoVersion: go1.12.5
Compiler: gc
Platform: linux/amd64
Ksonnet Version: 0.13.1
Logs
$ argocd app sync argocd
FATA[0030] rpc error: code = FailedPrecondition desc = Get https://github.com/cybozu-go/neco-apps.git/info/refs?service=git-upload-pack: dial tcp 52.69.186.44:443: i/o timeout
Have you thought about contributing a fix yourself?
Yes.
But currently I have no specific fix because I don't know whether this behavior is by design or not.
@morimoto-cybozu this is currently expected, by design. We did not want to offload all github interactions to repo server, just the expensive ones requiring cloning, disk space, etc... The queries that the API server still performs, are lightweight queries (e.g. resolve ambiguous revisions, validate repo exists, credentials are valid, etc...). For these interactions, we did not want to replicate all git API requests in the repo server.
Most helpful comment
@morimoto-cybozu this is currently expected, by design. We did not want to offload all github interactions to repo server, just the expensive ones requiring cloning, disk space, etc... The queries that the API server still performs, are lightweight queries (e.g. resolve ambiguous revisions, validate repo exists, credentials are valid, etc...). For these interactions, we did not want to replicate all git API requests in the repo server.