Hacker News Reader

Comment by pmig | Hacker News Reader

We are absolutely seeing a lot of snowflake clusters in the wild. This is also a hot topic on all cloud native conferences I attended lately.

Platform teams try to create internal developer platforms to further standardize Kubernetes configurations across teams and clusters, where developers can only do minor modifications. From my experience we want to reduce snow flake configurations. This is also a reason why we created Glasskube in the first place.

> - authoring helm charts sucks

Yes, 100% and we are on a mission to change this in future.

> - managing different values per environment

Glasskube packages are still configurable, but come with meaningful default values.

> - connecting values across charts so I don't have to

This is already possible, you can reference package configuration values from other packages easily via Glasskube, not needing to provide the same values multiple times.

View on HN

> This is already possible, you can reference package configuration values from other packages

This misses the point, what we need is something more like Terraform, which has a way to get dynamic information from resource values that are assigned by the system. One such example would be the secret that the postgres operator generates for connecting in the api server that needs access.

> > - managing different values per environment

Most charts already come with meaningful defaults. The issue is that you need simpler defaults for multiple environments that the user doesn't have to think about. There ought to be some higher level information coming into the pipeline that tells the tool what environment I'm working with and assign certain values automatically.

> Yes, 100% and we are on a mission to change this in future.

Configuration needs a proper language. Please avoid Yaml and something bespoke. There are a few configuration languages emerging, CUE is my personal pick in the horse race.

Thanks for clarifying your inputs.

> This misses the point, what we need is something more like Terraform, which has a way to get dynamic information from resource values that are assigned by the system. One such example would be the secret that the postgres operator generates for connecting in the api server that needs access.

It is also already possible to inject values from secrets during runtime. You can for example create a Glasskube package that has a dependency on cnpg and add a `cluster.yaml` to your package and then dynamically patch the connection string (or credentials) from it to your deployment.

See the "ValueFrom" section of our configuration documentation for the exact inner workings: https://glasskube.dev/docs/design/package-config/

> See the "ValueFrom" section of our configuration documentation

... this is what we have today, how do I know what value to patch in from, like what is the name of the secret?

Looking at that link makes me think this is like another layer of helm on helm, especially with the same go template values in yaml that are going to be fed into helm templates under the hood.

Putting more yaml on top of templated yaml is not the way to create the next package manager for k8s.

Agreed, this makes little sense to me.

Fundamentally there’s no such thing as a k8s “package”. OLM is great for packaging operators, but I don’t see why we need yet another Helm.

It was a mistake that shouldn’t be repeated.

Reply on news.ycombinator.com