[k8sagic]

I think you are marketing this thing wrong.

This has very little to do with helm. For me helm is primarily not a package manager, its a templating language and a way of configuring and installing it to a k8s cluster happens through kubeapps, helm cli or argocd.

This approach also kills for me the really awesome IaC paradigma: I bootstrap ArgoCD and after that, reference only git repos.

Your demo doesn't talk about HOW someone would use your templating features (like your 'form' support) but shows everything besides that.

I honestly like this as i'm still having the feeling that something is wrong with helm, but the way you are approaching it, i think it will fail. It will not gain enough traktion as bigger companies do not need your tooling. Kubeapps works really well and helm too (you want to replace helm, you probably will keep the helm support in there for a long time).

The problems helm have is: its getting convoluted when helm charts become big. The templating folder is a shit place for basically having everything in there, yaml is not that good for templating and values.yamls become way to big.

[pmig]

Our demo is more end user focused. You can find more information about our configuration options in our package configuration documentation: https://glasskube.dev/docs/design/package-config/

[k8sagic]

So you combine helm with kustomize patching?

that just solves a subset of issues helm and kustomize have right now.

[pmig]

Yes we do, in fact you can find the exact comparison here: https://glasskube.dev/docs/comparisons/helm/

[redrove]

I don’t mean for this to sound condescending or dismissive, BUT if you don’t think Helm is primarily a package manager you haven’t worked with infrastructure deployed in k8s much.

[k8sagic]

I'm running a 500 node cluster, 3 private ones and 5 in an opensource context.

I see this primarily from a business/ops perspective and i do not install helm charts manually through the cli besides for testing.

We provide kubeapps as the packagemanager / interface for providing helm charts and cirumventing package manager features of helm.

For smaller use, we use ArgoCD for IaC and the helm charts are only there for having a package to reference. Again no usage of helm as package manager

[redrove]

I’ve been doing this for about 8 years and have seen a few hundred clusters at dozens of orgs, been using GitOps for the last 4ish years.

Invariably they all involved using helm as a package manager to deploy off the shelf infrastructure with minor adjustments. I still don’t see your point, we can just agree to disagree.

[k8sagic]

I'm happy to discuss this topic and to clarify it.

For me the 'package manager' aspects are more than the templating and having a zip file. For me it is more what apt etc. do

So using helm and its remote repositories, using the helm cli etc.

But we use kubeapps or ArgoCD to install the helm packages and download all helm charts before we deploy them (due to security requirements).

We leverage 100% IaC. Therefore we bootstrap ArgoCD and than install everything through ArgoCD. Only helm charts for our customers/collegues are installed through kubeapps.

[redrove]

I don’t doubt your experience and what you do at your org, yeah that falls into a bit of a different category since you use kubeapps.

I guess what I’m saying is: in my experience across many organizations, helm is indeed treated more like a package manager (like I described above). Your workplace seems to be in the minority.

Hope that made sense :)