Support Helm v3

[StianOvrevage]

Is your feature request related to a problem? Please describe.

Argo now uses Helm v2. Helm v2 requires the tiller server running in the Kubernetes cluster. Securing tiller and Helm v2 is a royal PITA.

Describe the solution you'd like

Helm v3 is now in Beta 3 and does away with the server-client model. Helm v3 is a pure client-only application. I would like to be able to use Helm v3 in argo to deploy helm charts without all the complexity of setting up a secure Helm v2 environment.

Have you thought about contributing yourself?

I'm joining your Slack since it seems like a good and healthy project that I wish succeeds. On the technical side I'm still trying to wrap my head around all the moving parts in argo/cd/ci/ui/events/workflows so I'm a long way from being able to contribute with code and (accurate) documentation :)

[jannfis]

Hi @StianOvrevage, ArgoCD uses helm template to generate the manifests for deploying charts to the cluster. It does not require nor use the server-side tiller component.

[StianOvrevage]

Ok. Thanks for the quick reply. I guess that means I cannot use helm ls etc to manage releases in the cluster then, or does that still work?

[jannfis]

Well. Of course, you could do that if you install tiller and also install some software using helm install - you can do that in parallel to using ArgoCD within the same cluster, they are not mutually exclusive (you should just take care to not try to manage the same application/resources with both tools).

But the ArgoCD way would be to use argocd app <list|add|...> to manage your applications (also those that were installed through ArgoCD via Helm charts).

I think with the much improved Helm support coming with v1.3, it would be a piece of cake to update a deployed Helm chart from vX to vY with just updating a property of the ArgoCD application resource.

[rytswd]

Apart from the tiller discussion, I can see Helm v3 also comes with a few additions in its chart handling. I suppose Capabilities Built-in Object support would be something ArgoCD needs to handle. I'm not sure what else would be required when ArgoCD works out with helm template - would requirements.yaml to Chart.yaml and Chart API version bump have any impact? If it doesn't, as long as we don't use the .Capabilities, Helm v3 features can be safely used already?

[alexec]

Changes:

• Files in crds/ is a CRD and needs to be in the PreSync phase. crd-install is no longer supported.
• No delete policy seems to imply before-hook-creation.

See #2737.

[kevinheins]

Just tried to create an application using a Helm repository with v3 chart. I received this error:

argocd-server-64b6d9648c-lfs9f server time="2019-11-21T18:53:58Z" level=error msg="finished unary call with code Unknown" error="rpc error: code = Unknown desc = `helm inspect values .` failed exit status 1: Error: apiVersion 'v2' is not valid. The value must be \"v1\"" grpc.code=Unknown grpc.method=GetAppDetails grpc.service=repository.RepositoryService grpc.start_time="2019-11-21T18:53:58Z" grpc.time_ms=131.724 span.kind=server system=grpc

Looks like that the Chart API version bump would need to be addressed.

[ecout]

Just tried to create an application using a Helm repository with v3 chart. I received this error:

argocd-server-64b6d9648c-lfs9f server time="2019-11-21T18:53:58Z" level=error msg="finished unary call with code Unknown" error="rpc error: code = Unknown desc = `helm inspect values .` failed exit status 1: Error: apiVersion 'v2' is not valid. The value must be \"v1\"" grpc.code=Unknown grpc.method=GetAppDetails grpc.service=repository.RepositoryService grpc.start_time="2019-11-21T18:53:58Z" grpc.time_ms=131.724 span.kind=server system=grpc

Looks like that the Chart API version bump would need to be addressed.

That's most likely because the Chart version changed between Helm v2 and v3:
https://github.com/helm/helm/releases -> Compatibility with Helm v2

Helm 3 introduces a new Chart version (v2). This version is more compact than the previous Helm charts. Information that was once spread across multiple metadata files has now all been collected into Chart.yaml. A few rarely used features have been removed from charts, but only after a survey of all public charts indicated that less than 1% of them used the features (See below for more).

[mmaask]

It seems to work fine if char version is left at v1, but the tiller stuff that argo creates is unnecessary as it uses only helm template. Would hope we could have proper support for Helm 3 though.

[shreychen]

I met below error when create an HelmV3 application. Is there an ETA for supporting Helm 3?

Unable to create application: application spec is invalid: InvalidSpecError: Unable to get app details: rpc error: code = Unknown desc = helm inspect values . failed exit status 1: Error: apiVersion 'v2' is not valid. The value must be "v1"

[lebenitza]

There are some corner cases where it might make sense for Argo to support v3 ( requirements.txt moved to Chart.yml, v2 instead of v1, hooks, more here: https://helm.sh/docs/topics/v2_v3_migration/ ) but it doesn't need to as it uses helm mostly for template compilation, no tiller no anything. No need to rush.

Most public charts are still Helm2, they won't be migrated soon. Just make sure you use helm2 cli locally when developing your own charts.

If someone uses helm cli to install charts but at the same time using ArgoCD, that's a total other issue.

For you, might be as easy as doing what @mmaask did.

[omgapuppy]

I'd argue that v3 support makes sense - most orgs would welcome getting rid of tiller with open arms & developing charts using helm v2 is just backwards, considering v2 will be EOL.

There are some corner cases where it might make sense for Argo to support v3 ( requirements.txt moved to Chart.yml, v2 instead of v1, hooks, more here: https://helm.sh/docs/topics/v2_v3_migration/ ) but it doesn't need to as it uses helm mostly for template compilation, no tiller no anything. No need to rush.

Most public charts are still Helm2, they won't be migrated soon. Just make sure you use helm2 cli locally when developing your own charts.

If someone uses helm cli to install charts but at the same time using ArgoCD, that's a total other issue.

For you, might be as easy as doing what @mmaask did.

[rcasper]

I'd argue that this needs to be prioritized higher, I already have development teams that I support shifting wholesale from Helm 2 to Helm 3, and I cannot deploy their charts with Argo because it doesn't recognize the new Helm v2 API.

[travisghansen]

Yeah, the trouble is the community will start building charts for v3 leaving argo unable to render all community charts unfortunately. I've been working on a helmfile plugin and added support to render with both helm-v2 and helm-v3 if anyone is interested. I'll be putting the script on github shortly but ultimately considering adding it as a first class plugin.

[rbkaspr]

(previously commented as @rcasper, my old account).

Would it make more sense to either rename this ticket or create a new ticket specifically for adding v2 Helm API support to Argo CD, since that seems to be the main issue at play here?

[rbkaspr]

Looks like Helm 3 is on the roadmap for v1.5 (est Feb 28 2020), hopefully that pans out as advertised.

[travisghansen]

If anyone really needs v3 now I created a very crude wrapper script available here:
https://github.com/travisghansen/argo-cd-helmfile/blob/master/src/helm-wrapper.sh

The idea is to download the script and replace /usr/local/bin/helm with the script. Subsequently download binary files for both versions of helm as helm-v2 and helm-v3. It defaults to use helm-v2 but you can set the HELM_BINARY ENV variable to override that. This is very crude but should be fine for simple setups.

EDIT: made a small change that tries to detect v3 charts (apiVersion: v2) and forces 3 in those scenarios. Doesn't help for subcharts and the like, but again, it's crude :)

[julienMichaud]

This is a huge con for me atm, I can't upgrade to Helm3 because ArgoCD don't support it (yet)...

[Aliabbask08]

@julienMichaud ArgoCD support helm3 apiversion:v1...but dont support v2

[Aliabbask08]

@julienMichaud ArgoCD support helm3 apiversion:v1...but dont support v2

so by default helm3 generate v2..please check this out!

[julienMichaud]

As a workaround, one of my colleague @jjaniec added the following values for the Helm Chart.

server:
  service:
    type: NodePort
  extraArgs: { insecure: true }



installCRDs: false

repoServer:
  volumes:
  - name: custom-tools
    emptyDir: {}
 
  initContainers:
  - name: download-tools
    image: alpine:3.8
    command: [sh, -c]
    args:
      - apk add curl &&
        wget -qO- https://get.helm.sh/helm-v3.0.2-linux-amd64.tar.gz | tar -xvzf - &&
        mv linux-amd64/helm /custom-tools/helm-v3 &&
        wget -qO- https://storage.googleapis.com/kubernetes-helm/helm-v2.12.3-linux-amd64.tar.gz | tar -xvzf - &&
        mv linux-amd64/helm /custom-tools/helm-v2 &&
        curl https://raw.githubusercontent.com/travisghansen/argo-cd-helmfile/master/src/helm-wrapper.sh > /custom-tools/helm &&
        chmod 777 /custom-tools/helm
    volumeMounts:
      - mountPath: /custom-tools
        name: custom-tools
  volumeMounts:
  - mountPath: /usr/local/bin/helm-v2
    name: custom-tools
    subPath: helm-v2
  - mountPath: /usr/local/bin/helm-v3
    name: custom-tools
    subPath: helm-v3
  - mountPath: /usr/local/bin/helm
    name: custom-tools
    subPath: helm

We use the workaround created by @travisghansen for that.

[jessesuen]

Starting work on this now and will be part of Argo CD v1.5.

Although Helm v3 is supposed to be backwards compatible to Helm v2, I found at least one issue which doesn't work in v3 that used to work in v2:
helm/helm#7326

I suspect there might be potentially more backwards compatibility issues. Thus, we'll initially take an approach where Argo CD bundles in both helm v2 and v3 binaries, and will switch on apiVersion: v2 vs. apiVersion: v1 in the Chart.yaml and invoke the helm 2 binary vs. helm 3.

If desired (or if it turns out there are more discrepancies between v2 vs. v3), we could possibly provide a tuning environment variable to force which helm binary to use.

[davidkarlsen]

Helm3 can still install a v1 chart. Could it be controlled in some other manner?

[hayorov]

@jessesuen I'm happy to hear that you are started working on Helm 3 support, I'm doing the same in the private space. It would be nice if you could share some insights, estimations or maybe alpha/beta code. I'd like to help lemme know if you guys cappable to receive some help on this.

Although Helm v3 is supposed to be backwards compatible to Helm v2, I found at least one issue which doesn't work in v3 that used to work in v2:
helm/helm#7326

If you want to know our (enterprise/corporate) opinion on v2 vs v3 we started using Helm v3 due to tillerless and namespacing (read: no security issues and operational fuss with extra service in the cluster), so Helm 3 is our default.

[shinebayar-g]

Ok. Thanks for the quick reply. I guess that means I cannot use helm ls etc to manage releases in the cluster then, or does that still work?

Even though helm v3 is supported, this part is left out. Pls vote and join the latest discussion for the missing feature here.

[crenshaw-dev]

There's discussion happening here as well: #8591