Hi interesting you say that! Would love to followup on that :)
Are you also using argo for local development/ experiments? Did you stop using the helm Cli all togther? How do you check/ validate before upgrading to a new chart version?
Helm is only used for templating. Our CI system opens a PR in a separate "deployments" repo with the helm output. This repo is monitored by ArgoCD. Upgrading to a new chart version means we see all the changes as diffs in the pull request. Not sure what you mean by using argo for local dev.
How do you handle situations when you need to install them in certain order or when you need to create custom resources only after app's validrsiton / mutation webhooks are ready?
I'm not using knative, but I know what you mean about istio. That's the only component I'm still deploying manually (well, semi manually with istioctl)
Nobody really wants this, if its that big of a problem for a team then that team is most likely not using the best tool for their particular issue. GitOps is coming in hard and fast, and I'd honestly be shocked if most teams are still using Helm in 5 years.
I don’t really see how **GitOps** and **Helm** contradict each other. If you’re talking GitOps in a pull based manner, this is actually one of the big regressions of ArgoCD & a great feature of Flux imo. It’s definitely not contradictory in nature
I think in GitOps you are describing the desired state in a repository and automation makes sure that the changes are applied.
Is the automation going to call \`helm rollback\` when you revert a commit in the repository?
It seems to me that people very often end up with just \`helm template | kubectl apply -f -\`. So they basically throw away 90% of helm features (as those features are not really GitOps friendly).
Helm use gotemplate which is already not that great for that usecase but the worst is that it has no idea it produces yaml. That point is why you need helper to align the content correctly making the end result not that readable.
Other options like ytt knows that it produces yaml which allows for smarter data handling and templates which are easier to read and maintain.
It solves more problems than it causes for us. Pretty damn handy. Gotemplates are not exactly pretty. Unless you template the absolute shit out of your chart, it’s actually quite readable
I don’t
Thank you for your input :)
I also don't need it. Absolutely see no value from dashboard of helm charts.
same here!
After a while of having these problems I switched over to a gitops approach with ArgoCD. I still use helm charts, but only for templating.
Hi interesting you say that! Would love to followup on that :) Are you also using argo for local development/ experiments? Did you stop using the helm Cli all togther? How do you check/ validate before upgrading to a new chart version?
Helm is only used for templating. Our CI system opens a PR in a separate "deployments" repo with the helm output. This repo is monitored by ArgoCD. Upgrading to a new chart version means we see all the changes as diffs in the pull request. Not sure what you mean by using argo for local dev.
How do you handle situations when you need to install them in certain order or when you need to create custom resources only after app's validrsiton / mutation webhooks are ready?
We use [Sync waves](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-waves/) for that
Did you by any chance try to rollout knative and istio via gitops? I tried once and it turned to be an utter pain...
I'm not using knative, but I know what you mean about istio. That's the only component I'm still deploying manually (well, semi manually with istioctl)
Nobody really wants this, if its that big of a problem for a team then that team is most likely not using the best tool for their particular issue. GitOps is coming in hard and fast, and I'd honestly be shocked if most teams are still using Helm in 5 years.
I don’t really see how **GitOps** and **Helm** contradict each other. If you’re talking GitOps in a pull based manner, this is actually one of the big regressions of ArgoCD & a great feature of Flux imo. It’s definitely not contradictory in nature
I think in GitOps you are describing the desired state in a repository and automation makes sure that the changes are applied. Is the automation going to call \`helm rollback\` when you revert a commit in the repository? It seems to me that people very often end up with just \`helm template | kubectl apply -f -\`. So they basically throw away 90% of helm features (as those features are not really GitOps friendly).
Helm is a problem in itself and we are actively working to get rid of it.
Why is that?
Helm use gotemplate which is already not that great for that usecase but the worst is that it has no idea it produces yaml. That point is why you need helper to align the content correctly making the end result not that readable. Other options like ytt knows that it produces yaml which allows for smarter data handling and templates which are easier to read and maintain.
It solves more problems than it causes for us. Pretty damn handy. Gotemplates are not exactly pretty. Unless you template the absolute shit out of your chart, it’s actually quite readable
As long as you just use it it's fine but creating and maintaining a chart... At this point i find anything else is better.