4 ms·
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 wi
by pmig 3y ago
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.
- nikau 3y agoAnother layer of abstraction will surely simplify things
- pmig 3y agoDid 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.