Argo-cd: API Server communicates with the Git repository directly

Created on 19 Jul 2019  路  1Comment  路  Source: argoproj/argo-cd

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:

  1. Setup Argo CD in the environment where a proxy is mandatory for outgoing connections
  2. Set environment variables for argocd-repo-server; HTTP(S)_PROXY to the proxy URL and NO_PROXY to 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 server
  3. Execute argocd app sync APP for an application with a target revision of branch/symbol/tag
  4. See error

Expected 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.

bug

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.

>All comments

@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.

Was this page helpful?
0 / 5 - 0 ratings