Argo-cd: Use cluster name instead of cluster URL to create an app

[xoanmi]

Summary

Be able to use cluster name instead of cluster URL when creating an app

Motivation

Sometimes, especially in scenarios with several clusters, could be hard to determine the correct cluster where deploy applications by the URL

Proposal

Allow use cluster name in the --dest-server flag on the argocd app create command.

argocd app create guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path guestbook --dest-namespace default --dest-server in-cluster --directory-recurse

[sergimrz]

This would be a good enhancement as it's easier to automate stuff using the cluster name than the api url address. Also would be easy to implement as the cluster name is defined in the secret that contains the information of the clusters.

[kenske]

I think this is already being worked on: https://github.com/argoproj/argo-cd/pull/3944

[xoanmi]

I think this is already being worked on: #3944

Hi @kenske, is this #3944 enabling the usage of the name also in both the API and CLI? Indeed is what we are looking for as we would like to automate the full process of creating apps in our pipelines and the URL is something complex to guess when using a PaaS.

[lcostea]

On #3944 I am adding the support for the UI, on the cli there is already a flag --dest-name; there were a lot of discussions if we should use --dest-server and see if it is an url passed or a simple name, but in the end we went with a new flag.
It should already work when creating an app:
https://github.com/argoproj/argo-cd/blob/1a36fd178abf63b54b33e1ef47a25b8c9381a0e1/cmd/argocd/commands/app.go#L759

[xoanmi]

Thanks @lcostea, we will wait until this will included on a stable release 💯

[roylee17]

Is it possible to support a list of servers?
Simple load balancing or even just failover would be very helpful.
Thanks!

[igaskin]

Thanks @lcostea, we will wait until this will included on a stable release 💯

Btw, this is now available for use. The cluster name can be specified in as app.spec.destination.name in the application spec. We can probably close this issue now.