4 ms·

I've had to use helm and argocd in anger at work, and I feel like the real problem is not helm, nor argocd. They are tricky to learn but in general pretty stra

by cbanek 2y ago

I've had to use helm and argocd in anger at work, and I feel like the real problem is not helm, nor argocd. They are tricky to learn but in general pretty straightforward once you get it. What was really annoying was the constant moving and changing the yaml that kubernetes wanted. After you update your cluster and things stop working, it's really not about the layers on top, but it's about kubernetes and having to keep up with the new beta versions and also sunsetting other things.

TheDong 2y ago
> I feel like the real problem is not helm, nor argocd ... What was really annoying was the constant moving and changing the yaml that kubernetes wanted. That to me sounds like you're angry at helm and argocd, but don't realize it. The kubernetes apiserver publishes all the resources it supports, including custom-resource-definitions, including typed specifications that can be used to validate what you're submitting client-side. If helm weren't a dumb layer of yaml templating, it could tell you locally, like compiling a typed programming language, "this helm chart won't work on your cluster because you have the beta version of this CRD and need the alpha version", or it could even transform things into the correct version. The kubernetes API provides everything that's needed to statically verify what Groups/Kinds/Versions exist, and tooling like helm is just too dumb to work with it.
- arccy 2y ago
  That's what the --api-versions in helm is for. If you look at the helm commands argocd uses you'll see a very long string of flags that pass every available api version to helm.