Helm repository as first class Argo CD Application source

[mduarte]

So far the only source for Argo CD application are git repos (followed by a path and a target revision). What about supporting helm repositories as Application sources as well?

Leveraging Official Helm charts

To leverage some of the official helm charts, we are creating Argo CD applications pointing to the helm/charts GitHub repo (where the resources of the official charts are managed).

Such application would look something like this:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: elasticsearch
spec:
  source:
    repoURL: https://github.com/helm/charts.git
    path: stable/elasticsearch
    targetRevision: 46b1348dccaa800ae75b46be7c3faf7adee9aecc
    componentParameterOverrides:
    - name: cluster.name
      value: my-elasticsearch
...

Problems with this approach:

1. No proper versioning. Instead of the helm chart version, we need to use the commit sha
2. All parameters need to be overridden using the componentParameterOverrides. This list can sometimes become very long (especially in these public charts) and cumbersome to manage
3. Only works for charts backed by a public GitHub repo

Helm repository as an Argo CD Application source

We may now be in a situation where teams would like to publish their charts (during a release step) into a Helm repo. In this case we would like to create applications pointing directly to the helm repo instead of the multiple GitHub repos which hold the actual templated manifests. In fact, we may not even have access to some of those GitHub repos.

What do you guys thing about supporting such application source?
Suggestion:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: elasticsearch
spec:
  source:
    type: HelmRepo
    repository: https://kubernetes-charts-incubator.storage.googleapis.com
    name: elasticsearch
    version: 1.9.2
    componentParameterOverrides:
    - name: cluster.name
      value: my-elasticsearch
...

This would address the issues 1. and 3. mentioned earlier.

The following workaround - #938 (comment) - has been suggested to address this issue. However, this truly feels like a hack and it quickly gets very tedious to have to create a shallow chart for every upstream original chart.

How to avoid the infinite list of componentParameterOverrides ?

The application changes suggested above would address points 1. and 3. but not really do anything about 2. I am also aware that a proposal redesign of the componentParameterOverrides is in progress here - #1141.

I would argue however that ideally it would be great to override values in helm charts in a values file like manner. What if instead of a list of parameters to be passed to --set during helm template, we would be able to specify a values object that would override the ones in values.yaml from the chart source.

Suggestion:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: elasticsearch
spec:
  source:
    type: HelmRepo
    repository: https://kubernetes-charts-incubator.storage.googleapis.com
    name: elasticsearch
    version: 1.9.2
    values:
      cluster:
        name: my-elasticsearch
      image:
        repository: "docker.elastic.co/elasticsearch/elasticsearch-oss"
        tag: "6.5.0"

fyi, some of it was inspired by the HelmRelease CRD by flux: https://github.com/weaveworks/flux/blob/master/site/helm-integration.md

[jessesuen]

Given helm's ubiquity, and the fact that a helm chart repo and its use of semantic versioning are conceptually similar to git repos + commitSHA, in terms of immutability. I think I am on-board with this feature request. I agree with the point that having a shallow chart to reference an upstream chart feels like a hack.

[alexec]

Pushing back to v1.1.

[hobti01]

Many values contain sensitive information (passwords). CRDs are not protected like Kubernetes Secrets. It would be great if, in addition to inline values, a Secret object could be referenced by name. The Secret could be required to have a 'values' key to override the default and/or provided values.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: elasticsearch
spec:
  source:
    type: HelmRepo
    repository: https://kubernetes-charts-incubator.storage.googleapis.com
    name: elasticsearch
    version: 1.9.2
    values: {}
    secretName: my-sensitive-values

[salla2]

Given helm's ubiquity, and the fact that a helm chart repo and its use of semantic versioning are conceptually similar to git repos + commitSHA, in terms of immutability. I think I am on-board with this feature request. I agree with the point that having a shallow chart to reference an upstream chart feels like a hack.

Is this request been addressed? if yes could you provide me sample snippet how to overwrite upstream helm repo with local repo overrides please.

[zeph]

I'm not sure how this is supposed to be used... since I cannot add existing public 1st class repos

missing documentation update, perhaps? or related to issue #2826 ?

[test-account-0]

I'm not sure how this is supposed to be used... since I cannot add existing public 1st class repos

missing documentation update, perhaps? or related to issue #2826 ?

I think You don't have to add public helm repos.

This thing works for me:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: airflow
  namespace: ops
spec:
  project: default
  source:
    repoURL: https://charts.bitnami.com/bitnami
    chart: airflow
    targetRevision: 6.1.1
    helm:
      values: |
        image:
          tag: 1.10.10-debian-10-r0
  destination:
    server: https://kubernetes.default.svc
    namespace: ops
  syncPolicy:
    automated:
      selfHeal: false