Most active commenters

    ←back to thread

    Broadcom to discontinue free Bitnami Helm charts

    (github.com)
    210 points mmoogle | 14 comments | 18 Jul 25 19:29 UTC | HN request time: 1.269s | source | bottom
    Show context
    dpkirchner ◴[18 Jul 25 22:16 UTC] No.44610377[source]▶
    Maybe this will finally break me of my habit of using helm charts, period.
    replies(4): >>44610605 #>>44610877 #>>44610954 #>>44612370 #
    1. cheshire_cat ◴[18 Jul 25 22:42 UTC] No.44610605[source]▶
    Why do you want to stop using helm charts? Genuine question, as I'm new to Kubernetes and helm.
    replies(4): >>44610615 #>>44610658 #>>44610858 #>>44611287 #
    2. chuckadams ◴[18 Jul 25 22:44 UTC] No.44610615[source]▶
    Write a few Helm charts and you'll understand why people want to stop using it. `nindent` will become a curse word in your vocabulary. It's a fine tool at the user level, but the DX is an atrocity.
    replies(2): >>44610629 #>>44610659 #
    3. bigstrat2003 ◴[18 Jul 25 22:46 UTC] No.44610629[source]▶
    I mean, I have written a few (like 5-10?) and I don't understand either. I find that Helm is quite a nice tool which does its job very well.
    4. NewJazz ◴[18 Jul 25 22:51 UTC] No.44610658[source]▶
    Consuming one that is well written isn't too much pain, IME. But writing or modifying one can be really annoying. Aiui the values.yaml has no type schema, just vibes. The whole thing is powered off using text templating with yaml (a whitespace sensitive language), which is error prone and often hard to read. That's basically the main issues in a nutshell, it may not sound like much, but helm doesn't exactly do a whole lot and it does that limited set of stuff poorly.
    replies(1): >>44610785 #
    5. cbzbc ◴[18 Jul 25 22:51 UTC] No.44610659[source]▶
    What are you planning on moving to ?
    replies(2): >>44611445 #>>44611736 #
    6. remram ◴[18 Jul 25 23:07 UTC] No.44610785[source]▶
    I share your dislike of Helm, but FYI there are schemas for values, see for example https://github.com/bitnami/charts/blob/main/bitnami/postgres... and docs https://helm.sh/docs/topics/charts/#schema-files
    replies(1): >>44611394 #
    7. zer00eyz ◴[18 Jul 25 23:15 UTC] No.44610858[source]▶
    I will leave it to others: https://noyaml.com
    8. EdwardDiego ◴[19 Jul 25 00:14 UTC] No.44611287[source]▶
    Golang string templating in a whitespace sensitive config language suuuuucks.

    I might use Helm charts for initial deploys of operators, but that's about it.

    Kustomize is, IMO, a better approach if you need to dynamically modify the YAML of your resources and tools like ArgoCD support it.

    9. NewJazz ◴[19 Jul 25 00:31 UTC] No.44611394{3}[source]▶
    Ah, I must have met some lazy charts then. Thanks for the correction. Still, it seems like that schema would end up a little inconvenient to integrate into your editor for writing the templates...
    10. chuckadams ◴[19 Jul 25 00:39 UTC] No.44611445{3}[source]▶
    Probably kustomize, as my needs are simple. If I care to get fancy, I’m pondering giving Yoke a try.
    replies(2): >>44611556 #>>44615448 #
    11. theteapot ◴[19 Jul 25 01:00 UTC] No.44611556{4}[source]▶
    What's wrong with `kubectl apply -f xxx.yaml`?
    replies(1): >>44611973 #
    12. dpkirchner ◴[19 Jul 25 01:34 UTC] No.44611736{3}[source]▶
    I'm using either opentofu(terraform) or plain yaml. I'm not a huge fan of HCL but at least it is structured and easily manipulated without worrying about whitespace.
    13. physicles ◴[19 Jul 25 02:17 UTC] No.44611973{5}[source]▶
    We use kustomize because we have four environments that run basically the same stuff (dev with k3s, test, and two cloud regions). If we didn’t use kustomize, we’d be forced to reinvent it to avoid duplicating so much yaml.
    14. davidham ◴[19 Jul 25 13:46 UTC] No.44615448{4}[source]▶
    I used kustomize to build an ArgoCD install at a previous company, and I was impressed at how powerful it was. Our setup was pretty involved, and kustomize was able to handle all the per-environment differences easily, and the code was easy to work with.