Hacker News Reader

Comment by gtirloni | Hacker News Reader

Skimming the readme, this seem focuses on reusing Helm charts but offering a supposedly more intuitive interface?

Does it change the way developers would work with YAML and Go templates or is it the same as in Helm?

We focus more on the installer experience, in the back we still use manifests and helm charts that will get deployed in the cluster, but the package operator will constantly sync them with central repository to make sure that the packages will stay up to date.

We didn't wanted to introduce a new standard in deployment method for our first preview to support as many packages as possible.

Another layer of abstraction will surely simplify things

Did you see our package manifest schema? We will add more information (dependencies, conflicts, etc.) into these package manifests, but keep the overhead low.

As a package manger also relies on the community and supported packages we don't want to introduce a new layer of abstraction that every package creator needs to implement.

But this doesn't do anything for packagers - making it easy to write new packages?

So far I think the best part of helm is installing/using packages - it's the terrible yaml-template soup that is the problem?

It helps packagers to distribute packages and package updates to the used. Think of it as the iOS app store for Kubernetes, we bridge the gap between publishing and installing a package, so we can help packagers get the latest version into the installers cluster and make sure the package is compatible with the installers cluster and - in a later version - support the packagers with crash logs and and bug reports.

maybe I'm misunderstanding the concept here - aren't all the dependencies and conflicts taken care at during the docker image creation phase?

Or are you talking about running dependent sidecars or something like that?

We are taking care of dependencies of other cloud native packages. For example the new Kubernetes dashboards has a dependency on cert-manager to generate certificates, or apps that have dependencies on databases or requirements for logging, monitoring or backups. All these dependencies point other cloud native packages that shouldn't / can't be installed in the same docker image.

right - in my experience that's probably the most insignificant thing to workout, but I guess if there's demand for it good luck.

Thanks!

Reply on news.ycombinator.com