Why is the native helm integration not working?

[tyriis]

Hi, related to #1672

I am really curious in the design decision, to delete helm releases after the deployment.
Maybe someone can give a feedback why this is required.

ArgoCD claims to be un-opinionated, it feels like a contradiction to not allow to interact with "my" known tools with existing helm releases.

I would encourage an opt-in/opt/out to be able to keep the helm release information, comparable tools like FluxCD are able to handle it even without deleting the helm informations.

[jannfis]

Hi @tyriis,

actually, Argo CD uses helm template under the hood to render Helm charts and reconciles the resulting YAML manifests to the target cluster. Since Argo CD does not use helm install, there will be no Helm release installed to the cluster (and, opposed to what was mentioned in #1672, we don't create and delete Helm releases on the cluster).

I can also imagine a lot of confusion arising when there's two tool competing about the final word on the same installed application, e.g. you have the Argo CD pinned to a Helm chart version X.Y.Z, and perform a manual upgrade of the same application using Helm to X.Y.Z+1

However, I think there are actually discussions going on making the Helm information available in the cluster. I can't seem to find the appropriate issue, tho.

[tyriis]

Hi @jannfis,

thanks a lot for the clarification.

Concerning the competition problem, yes you are right, but we have the same with other things in the ecosystem. For example, if we manually change a deployment it will be reconfigured during reconciling. Helm is by default just a tool and not an automation so when I upgrade with helm, it will be restored by Argo (as expected) having +2 releases in helm 1 for my manual changes and the other made by Argo.

I expect someone manually changing managed resources, is knowing what he/she is doing.

I am fine to not change backwards compatibility and let the user opt-in for the "native helm feature".

[Eugst]

when to expect "native helm feature"?

[tyriis]

@Eugst
Not sure if this is even considered, as far as I have understand so far. It is more a security topic then a feature topic. Please correct me if I am wrong, there is no way to prevent secret information to be protected when helm take over the final part, and there is a risk of exposing credentials/secrets to users in the argo-cd system that should be restricted.

[shinebayar-g]

+1, IIRC Helm v3 is client side only and have no server components. In theory ArgoCD could support Helm deployments (still could keep using helm template and implement correct behaviors) more than just templating. How much gap is there between helm install vs helm template? Feels like main helm command could be supported. For example, helm list , helm history, helm status etc are useful commands. As many others said it's similar to kubectl. Even if helm install or helm upgrade is not supported that's fine. It's no different than manual kubectl edits, and should be responsibility of the user, not argocd limitation.

Edit: Helm has a native Golang SDK which would allow ArgoCD to integrate with Helm natively.

[rowi1de]

Is there any way that ArgoCD could produce a warning when any chart / template uses native helm functions that might not be supported?

[crenshaw-dev]

I doubt there's a good general way to do this. Imagine a lookup in an if block: Argo would have no way of knowing if that lookup would ever be hit. Scanning dependencies would be even worse.

I think our best option is to catch errors caused by known incompatibilities and augment the error message with more information.

[rowi1de]

Is there list of helm features that don’t work? I’ve an issue with a 3rd party chart that uses e.g. print & printf .. but those are just Helm / go template functions not like lookup

https://github.com/bitnami/charts/blob/76926cbf89753107da9d8bfd1ebee10b84ed15be/bitnami/oauth2-proxy/templates/_helpers.tpl#L108

[crenshaw-dev]

There's scattered info in the Helm docs, but we definitely need a more centralized "what features are not available" block in docs.

I can't imagine why print or printf would not work. Want to open an issue?

[rowi1de]

Issue for updating the ArgoCD Docs?
I can do or also create a PR once I figured out

[rowi1de]

This is caused by the example in the docs it seems https://argo-cd.readthedocs.io/en/latest/user-guide/helm/#random-data
https://github.com/bitnami/charts/blob/76926cbf89753107da9d8bfd1ebee10b84ed15be/bitnami/redis/templates/_helpers.tpl#L229

[gioppoluca]

If I understand well Argo is not executing a helm install so if in the cluster there is something that does "things" as a result of an helm install it will not be done.
As an example in Rancher when you execute an helm install an entity of Apps type is created in the Rancher catalog and this is functional to have Rancher understand that there are things and it relyes on it to activate pieces in its UI.
Is it possible to have Argo behave like an helm install?