[pmig]

You can simply run "glasskube install cert-manager" or in the future "glasskube install [your package]" and glasskube makes sure all the dependencies get transitively installed.

In addition our GUI is served locally from the client and just creates package Cars, which then will be picked up by the package operator.

[chologrande]

I can simply run `helm install cert-manager` or `kubectl operator install cert-manager -n cert-manager --channel stable --approval Automatic --create-operator-group ` - both have dependency resolution.

Not trying to be negative here, trying to understand if there is value or functionality missing from established solutions, because it's not obvious to me.

[pmig]

Your feedback is definitely reasonable, I don't perceive it as negativity.

Let me elaborate on both examples:

1. Helm dependencies

As cert-manager doesn't have any dependencies this will work fine, but we saw in many other helm charts often a "bitnami postgres" or the kube-prometheus-stack included. These dependencies will be installed in the same namespace as the original chart gets installed. Which is not very transparent for the user. A classic example is the Bitnami Wordpress chart where the MariaDB chart is included. The MariaDB chart received a major update through a Wordpress chart update which resulted in a lot of broken Wordpress installations.

With Glasskube we try to separate these dependencies into separate packages, so we can update the MariaDB (Operator) independently from the Wordpress installation. So a Glasskube package will be able to request a database (CR) and if the CRD is not yet present in the cluster we will install the CRD provider (mariadb-operator).

2. OLM cli

If you only want to manage operators and are very skilled you can use OLM which will have a similar effect, but as I tried to explain with the Wordpress example, most packages will not purely be an operator but have some namespaces components (like deployments) and will require custom resources from operators.

We have not yet introduced this distinction, but will maybe add the two categories ClusterPackages (Operators) and Packages (Apps) which play together nicely.

Our aim is to not recreate the wheel, but give cloud native developers the possibilities to make sure operator dependencies are met and Kubernetes users a simple CLI und GUI tool to get started without the need of copy pasting some helm commands that somebody else will update with different values or who does not read the changelog of a helm chart to fully understand the consequences.

Happy to get more of your knowledge to make Glasskube a better product, as we are still in the technical preview phase.