Make it possible to set release name different from argcd app name.

[peterbosalliandercom]

Now the argocd app name is used as release name in the helm templating. It would be great if it is possible to use a seperate app name and release name like this:

argocd create app artifactory-prd --release-name artifactory ....
This way we can create apps for production cluster and test cluster with the same release name.

Reason we need this is that not all helm charts have the possibility to use the nameOverride parameter.

[jessesuen]

We briefly considered this, but I think there may have been issue about the combination of:

1. our decision to inject app.kubernetes.io/instance to be the app name
2. using app name as helm release name (i.e. helm template --name <appname>)
3. modern helm charts (created after helm 2.12?) also using release name in app.kubernetes.io/instance label.

I think the error scenario is:

1. modern Helm charts created using helm create (v2.12) will auto-generate labels, including app.kubernetes.io/instance = <release name>
2. Argo CD overrides this label with app.kubernetes.io/instance = <argocd app name>
3. Since the two would be different, it may cause problems for the helm chart.

[jessesuen]

Reason we need this is that not all helm charts have the possibility to use the nameOverride parameter.

That said, I do think this is a valid request. We are also facing similar issue about wanting to set release name in helm charts where app.kubernetes.io/instance is not used by the chart at all. I think one possibility is to detect and possibly error when we detect that user set a release name, and the chart is wanting to use release name in app.kubernetes.io/instance.

[igaskin]

This requests seems especially important when managing helm charts installed from a helm repository, instead of installing the chart from source. As a workaround I removed all references to {{ .Release.Name }} in my local helm chart, and substituted it with a consistent name. Keep in mind that if the release name is used as a label selector, it cannot be changed once set: kubernetes/kubernetes#50808

[jessesuen]

I think it's fine to support releaseName, but we need to detect and error if the helm chart is using app.kubernetes.io/instance: <release-name>, and Argo CD wants to do app.kubernetes.io/instance: <application-name>.

For example, this the following situation:

Application Spec:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: foo
spec:
  source:
    helm:
      releaseName: bar

Helm template:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "helm-test.fullname" . }}
  labels:
    app.kubernetes.io/name: {{ include "helm-test.name" . }}
    helm.sh/chart: {{ include "helm-test.chart" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
    app.kubernetes.io/managed-by: {{ .Release.Service }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app.kubernetes.io/name: {{ include "helm-test.name" . }}
      app.kubernetes.io/instance: {{ .Release.Name }}
  template:
    metadata:
      labels:
        app.kubernetes.io/name: {{ include "helm-test.name" . }}
        app.kubernetes.io/instance: {{ .Release.Name }}

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[eupestov]

This feature can help to solve the issue with consistently naming resources across multiple clusters or namespaces, but only for helm applications. And indeed many newer charts do use .Release.name in app.kubernetes.io/instance.

A more general fix would be to decouple application resource name from the deployed application name and make the latter scoped with destination server and namespace values.

[lcostea]

@jessesuen I am a little out of the loop on why argocd needs/wants to use app.kubernetes.io/instance: <application-name> but shouldn't it introduce its own labels, like helm does for helm.sh/chart: {{ include "helm-test.chart" . }}
This way there will be no clash and you can still have meta info that it was installed with argocd and the app it belongs to

[lcostea]

@jessesuen So will it make sense to use another label, specific to ArgoCD in order to save the application name on the deployment (and other resources)?
This would allow to decouple the application name from the release name.
Also I see that the release name overriding feature was there, but was removed, so it will not be too complicated to get it back. I could help on that. Just to figure out the labelling.