3 ms·
Did you see our package manifest schema? We will add more information (dependencies, conflicts, etc.) into these package manifests, but keep the overhead low.
by pmig 3y ago
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.
- e12e 3y agoBut 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?
- pmig 3y agoIt 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.
- nikau 3y agomaybe 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?
- pmig 3y agoWe 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.