Hacker News Reader

Comment by nikau | Hacker News Reader

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