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

The complete Operator capability level is a bit of a misnomer and very self serving and are often not operator specific, but assume the operator writer has implemented extra things. There not really

Hello Helm Team, We are using Helm in our product for the deployments and upgrade. We are looking at the next step of introducing the Kubernetes Operator for handling the Day 2 Operations. Going

Hey all, My apologies for not noticing this first, but this was the incorrect list to have started the actual voting on (Usually, the nomination happens here and the voting is to be conducted on the

+1 !

+1

+1 🎉👏

+1 for Scott

+1 Scott has been very helpful with the charts testing/releasing features and associated GitHub actions!

+1 Regards, Martin

+1 for Scott! thanks for all the work you do! Em qui., 16 de set. de 2021 às 21:08, Scott Rigby <scott@...> escreveu:

Hi again everyone 👋 Since last week's Helm dev call, I planned to self nominate to help with helm/helm triage via the new Triage role. I've also already been wanting to volunteer time to help

Hello everyone! As discussed during today's (Sept. 9) weekly Helm developer meeting, I'd like to nominate myself as one of the triage maintainers. I'm a software engineer at Red Hat and working on

Hi, I would like to propose a 'cascade' option for the uninstall and upgrade commands. The current implementation of these commands hardcodes metav1.DeletePropagationBackground and removes all