Hacker News new | past | comments | ask | show | jobs | submit login

When I check the packages repo, I see that they are yaml.files linking to helm packages. Is this only capable of deploying helm packages? Is there a packaging solution included too?



> We are still using Helm and Manifests under the hood. However, together with the community, we plan to develop an entirely new packaging and bundling format for all cloud-native packages.

Yes at the moment Glasskube packages wrap around Helm charts and manifests. We don't have a dedicated packaging format as of now.

We are actively looking into OCI images and other possibilities to bundle Kubernetes packages, but focus on features like multi namespace dependencies and simplicity at the moment.

How would you like to package Kubernetes packages or what should be avoided from your perspective?


This is the worst of both worlds.

Helm, as an abstraction layer, is a real pain in the ass. Having another abstraction layer here is pure madness.

I wish you luck, but I do not wish to board your boat.


This was what I understood too.

As a power Kubernetes user providing Kubernetes based paas to internal customers, we are not looking for more GUI or, abstractions over helm.

There are already a lot of solutions out there in this area like helmsman/argocd/helmfile/cross plane helm-provider. And we like kubernetes resources + gitops based automations over any other fancy tools.

Most of the time problems around helm is it's string based templating and lack of type safety. That's why timoni looks a more promising solution in this space. It's lack of packages is the limiting factor.

Another interesting approach is kapp-controller and carvel tooling. Packaging helm charts, OCI images, etc as OCI artifacts to use as a combined source is really interesting. We were considering using kapp-kontroller however our current dependence helm, and some architectural concerns caused us to pass on kapp-controller for now.

As to the question of what could be selling points towards a new "Package Manager" would be,

* Timoni like packages that has templating with type safety. * A large package pool, or * Abstraction over helm packages that could add type safety, or better yet automatic or at least semi-automatic conversion of helm charts (One can dream ;)) * Full management through kubernetes API / CRDs * Multicluster management, or fleet management.


Yaml files should be avoided.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: