| First off I just wanted to say I think it's great that you're attempting to tackle the problem that is Kubernetes package management. I work at a Kubernetes SaaS startup and spend many hours working with YAML and Helm charts every day, so I absolutely feel the pain that comes with it. That being said, I'm confused as to where Glasskube is positioned in solving this problem. In the title of this post, you are claiming Glasskube is an "alternative to Helm"; although in your documentation you have a "Glasskube vs Helm" guide that explicitly states that "Glasskube is not a full replacement of Helm". I'm trying to understand how these two statements can be true. To make things more confusing, under the hood Glasskube repositories appear to be a repackaging of a Helm repository, albiet with a nicer UI. From what I've gathered after reading the docs, Glasskube is being positioned as an easier way to interact with Helm charts - offering some easy-to-use tooling for upgrades and dependency management. To me, that doesn't exactly feel like it replaces Helm, but simply supplements my use of it, because it doesn't actually combat the real problems of using Helm. My biggest pain points, some of which I don't think Glasskube is addressing, that I think are at the crux of switching off Helm: - The arbitrary nature of how value files are laid out - every chart appears to have its own standards for which fields should be exposed and the nomenclature for exposing them - Helm releases frequently get stuck when updating or rolling back, from which they can't be fixed without needing to be uninstalled and reinstalled - I need to reference the Helm chart values file to know what is exposed and what values and types are accepted (Glasskube schema'd values files does address this! Yay!) Apart from the Helm chart values schema, I don't think Glasskube solves these fundamental problems. So I'm not sure why I would spend the large amount of effort to migrate to this new paradigm if the same problems could still cause headaches. Lastly, I would also concur with @llama052's comment, that an "update all" button will always be forbidden in my, and probably most other, companies. Considering the serious lack of standardisation that comes with Helm chart versioning (whether the app version changes between charts, whether roles or role bindings need to be updated, whether values have been deprecated or their defaults have changed, etc.), it's incredibly risky to update a Helm chart without understanding the implications that come with it. Typically our engineers have to review the release notes for the application between the two Helm chart versions, at least test in dev and staging for a few days, and only then can we feel comfortable releasing the changes - one chart at a time. Not to mention that if you are in charge of running a system with multiple applications, you probably want to use GitOps, and in that case a version upgrade would require a commit to the Git repository and not just a push of a button on the infra IDP. |