Hello everyone, Based on discussion in an issue I have decided to write up a HIP for allowing dependency overrides during helm install/update operations. Details can be seen in the merge request

Re-sending as a reply-all. Hi Andrey, Have you read through the threads on github? This particular discussion topic has been discussed at length.... Probably once every few months I'd say at

Hey! I want to make a feature HIP to add jsonnet templating to helm. Specifically, I want helm to have tanka-like functionality with plugged kubernetes libs. Motivation: 1. go templates have lots of

Hi Berin, Thanks for your comprehensive response. Best Reagrds, Sandip

Helm definitely has some wrinkles, and I've run into a few. So I would recommend separating your tasking. For example: Writing docker files and helm charts are separate activities, they deserve

This is a somewhat open ended question but I am looking for some real world, practical knowledge/experience about effort estimation for developing and maintaining Helm chart based products. Helm3 is

Just out of curiosity does anyone know how helm would behave if we used ValidatingAdmissionController webhook to deny the helm release to be modified ? I bet you could rough it out with

> I wasn't aware you could do that. Is it common practice for someone to replace a chart for an in place deployment? A common use case is to migrate from a public chart repository (like one published

Thanks for the link to the PR. That seems a bit different than what I had in mind. Those are great questions to include in the proposal. Here's some basic answers and a question for

Hey Justin! I like this idea. We've had similar proposals presented for resource update locks like https://github.com/helm/helm/pull/5290, though there were several design flaws preventing that from

I would like to propose a process to "lock" a helm release to a specific version so it is safe from `helm upgrade` and other situations that may cause unintended breaking changes. There are a variety

Hi, Following the HIP process, I'd like to know whether the use-case below already received some thoughts, and whether there are some suggestions on best user experience to support this use-case. I

Hi Teja, https://github.com/quintush/helm-unittest provides support for helm chart unit tests. Some alternatives are also listed in https://github.com/quintush/helm-unittest#related-projects--commands

Big +1 from me! When trying to automate chart uninstalls (e.g. in the context of operator-sdk's helm-operator), it is fairly unintuitive and complex to set things up in such a way to guarantee

JFrog https://Chartcenter.io services will be deprecated soon. Please read more about it at https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/

You'll have to forgive my ignorance on this one, but there is nothing I can see that explains this design decision--and it really makes creating multi-service deployments harder than it should be. In

Hi Mike, This seems like it could be very useful, especially during dev where there are more likely to be issues in the uninstall of the resources. Keeping the release would allow would give us a

So if I’m understanding correctly, you’re looking to validate that a particular resource provided by the user follows a certain schema. Kubernetes resources define a schema (also known as a

The idea is not to scan, but to validate that the specified secret is the right kind. I.e. the user specifies `example-secret`, and the helm chart fails if the secret that exists is not the right

The preferred method is requiring the user to set a value that points to an existing secret. If the user points to the wrong thing, then Helm should fail to deploy that release. We advise people not