4 ms·

This looks like an interesting take on package management. Would be cool for homebrew clusters and the like. However things like helmfile with renovate paired

This looks like an interesting take on package management. Would be cool for homebrew clusters and the like. However things like helmfile with renovate paired with a pipeline is my personal preference even if just for ensuring things remain consistent in a repo. The `update all` button for instance seems terrifying on a cluster that means anything at all. None the less it's still cool for personal projects and the like! The package controller reminds me a lot of Helm tiller with older versions of helm, and it became a big security issue for a lot of companies, so much so that helm3 removed it and did everything clientside via configmaps. Curious how this project plans on overcoming that.

pmig 2y ago
Thanks for your input, let me comment on your points one by one. > However things like helmfile with renovate paired with a pipeline is my personal preference even if just for ensuring things remain consistent in a repo. Glasskube packages can also be put inside a GitOps repository as every package is a CR (custom resource). (They can even be configured via the CLI using the `--dry-run` and `--output yaml` flags and than put into git. In addition we are working on pull request to support package updates via Renovate: https://github.com/renovatebot/renovate/issues/29322 https://github.com/renovatebot/renovate/issues/29322 > The package controller reminds me a lot of Helm tiller with older versions of helm, and it became a big security issue for a lot of companies, so much so that helm3 removed it and did everything clientside via configmaps. Curious how this project plans on overcoming that. As helm3 is now a client side tool only, that means that it can't enforce any RBAC by itself. OLM introduced Operator Groups (https://olm.operatorframework.io/docs/advanced-tasks/operator-scoping-with-operatorgroups/ https://olm.operatorframework.io/docs/advanced-tasks/operato...) which introduces a permissions on an operator level. We might introduce something similar for Glasskube packages. Glasskube itself will still require be quite powerful, but we can than scope packages and introduce granular permissions.

pmig 2y ago

Thanks for your input, let me comment on your points one by one. > However things like helmfile with renovate paired with a pipeline is my personal preference even if just for ensuring things remain consistent in a repo. Glasskube packages can also be put inside a GitOps repository as every package is a CR (custom resource). (They can even be configured via the CLI using the `--dry-run` and `--output yaml` flags and than put into git. In addition we are working on pull request to support package updates via Renovate: https://github.com/renovatebot/renovate/issues/29322 https://github.com/renovatebot/renovate/issues/29322 > The package controller reminds me a lot of Helm tiller with older versions of helm, and it became a big security issue for a lot of companies, so much so that helm3 removed it and did everything clientside via configmaps. Curious how this project plans on overcoming that. As helm3 is now a client side tool only, that means that it can't enforce any RBAC by itself. OLM introduced Operator Groups (https://olm.operatorframework.io/docs/advanced-tasks/operator-scoping-with-operatorgroups/ https://olm.operatorframework.io/docs/advanced-tasks/operato...) which introduces a permissions on an operator level. We might introduce something similar for Glasskube packages. Glasskube itself will still require be quite powerful, but we can than scope packages and introduce granular permissions.