+1 Karen would be a great addition in my opinion!

I accept the nomination!!

Thanks to Adnan for his service. Now that he has stepped down as a Helm Org maintainer, we have an opening. Per the process described in the governance docs in

Thanks very much to Matt for giving us feedback on this - we have addressed his feedback and added docs and testing to give everyone a better idea of what this would like like. If we could get the PR

Hello, I've developed a plugin to fetch values from a previous release helm-val it may be suitable for your case. Also you can found it here Best Regards, Hamza

Hi 👋 I would like to submit an idea to the helm project. I have a use case which is not covered by the existing Helm command line tool, here’s a description: At BlaBlaCar, we have canary

Hello all, As suggested by the contributing docs we are trying to vet a new feature idea with the community. The idea is to add configurable outputting of logs from hook jobs and pods on failure -

Hello all, As suggested by the contributing docs we are trying to vet a new feature idea with the community. The idea is to add configurable outputting of logs from hook jobs and pods on failure

Allen, Thanks for your patience as we worked through the vote. It can sometimes be a slow process. I want to welcome you as our newest triage maintainer. You now have the votes. Regards, Matt

Hi Joe and thanks for volunteering to help the Helm project! The maintainers will soon start the voting process on the maintainers mailing list. We'll be in contact with you once the process is

+1

I would like to nominate myself as a triage maintainer. I'm a staff engineer at D2iQ and have been using helm in production for many years. I've been attending the developer calls, shadowed a

I am working on the helm integration into the openshift/kubernetes tooling (VSCode/Eclipse/IntelliJ). So we need to generate a UI for the chart values. As the schema file is not mandatory, what is the

Matt, I do think the capabilities themselves are a useful construct for thinking about operators in general, whether implemented using operator-sdk or not. But of course outside the context of

Thanks for providing clarification with… I think there are a couple problems here, though. People are taking the levels as Helm stand alone vs operators in general. This has come up in numerous

Hi Anil, To complement and add to Paul and Matt's response. Helm and Operator serve separate purposes and can be used in combination to achieve your application packaging and distribution goal. An

I don't think they ever designed their lifecycle definition to be agnostic to operators. The page there is talking specifically about: Operator Capability Levels. So I don't knock them for being

That url is a bit misleading. Its describing their "helm based operator sdk"s capabilities. I have personally done more advanced things then possible with the "helm based operator sdk" can do using a

The "Operator Capability Levels" you reference are comparing helm-based operators, ansible-based operators, and go-based operators as supported by the operator-sdk. Those are the three operator types

I’d like to add to what Paul said. Helm and operators are two different types of things. They don’t solve the same problem. Think of it this way, would I ask apt or yum to implement ansible