Argo-cd: Remove kubectl in image and report client version in `api/version`

Created on 21 Sep 2020  路  7Comments  路  Source: argoproj/argo-cd

currently installed kubectl version for argoproj/argocd:v1.7.6:
Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.8", GitCommit:"35dc4cdc26cfcb6614059c4c6e836e5f0dc61dee", GitTreeState:"clean", BuildDate:"2020-06-26T03:43:27Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}

Is there any reason to not update to latest? We are testing argo-cd on a 1.18 cluster, this might solve some issues we have

Checklist:

  • [x ] I've searched in the docs and FAQ for my answer: https://bit.ly/argocd-faq.
  • [x ] I've included steps to reproduce the bug.
  • [ x] I've pasted the output of argocd version.

Describe the bug

kubectl is not up to date

argocd: v1.7.6+b04c25e
  BuildDate: 2020-09-19T00:50:44Z
  GitCommit: b04c25eca8f1660359e325acd4be5338719e59a0
  GitTreeState: clean
  GoVersion: go1.14.1
  Compiler: gc
  Platform: linux/amd6
bug tech-dept

All 7 comments

We actually no longer use the kubectl binary because we switched to using the kubectl golang library code. So updating the binary accomplishes nothing then changing what gets reported in /api/version. I think we should remove the binary from the image and report the kubectl client golang version in /api/version.

Is there any reason to not update to latest? We are testing argo-cd on a 1.18 cluster, this might solve some issues we have

We're actually already using v1.18 kubectl logic / library version.

Ah Thanks for the info :+1:, is it the same state for helm (using the sdk)?

No, helm we're still forking the binary

ok, thanks for the info 馃樃 . i wont close this myself since you added a label.

the job would be to remove from here:

should kubectx be removed as well? i see it referenced in the hacks scripts but not not in the dockerfile

I think we only want to remove kubectl from the Dockerfile that runs the argocd* binaries. The other occurrences are for devtools, and make sense to keep. I was looking at this and wasn't sure how to accomplish retrieving the version of a library from a compiled binary, short of injecting it at build time. For example we could append an additional variable to LDFLAGS

KUBEVERSION=$(shell cat go.mod | grep kubernetes | awk '{print $$2}')
...

override LDFLAGS += \
  -X ${PACKAGE}.version=${VERSION} \
  -X ${PACKAGE}.buildDate=${BUILD_DATE} \
  -X ${PACKAGE}.gitCommit=${GIT_COMMIT} \
  -X ${PACKAGE}.gitTreeState=${GIT_TREE_STATE}
  -X ${PACKAGE}.kubeClientVersion=${KUBE_CLIENT_VERSION}

Is this a reasonable approach, or is there something else that I'm not thinking of?

Also, does it make sense to update the VersionMessage proto and add another field for KubeClientVersion? It seems misleading to advertise KubectlVersion when it is not actually being used.

Was this page helpful?
0 / 5 - 0 ratings