1. cncf-helm@lists.cncf.io
  2. Messages
   Date   
Re: Does Helm has a plan to support the complete Operator maturity level?

Michael Hrivnak
 

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 operator-sdk, the three types (helm/ansible/go) are less relevant. It sounds like the messaging might be more clear if there was a version of the graphic that did not include the three types, but just focused on the levels themselves, for use when talking about operator capabilities in general. Do you think that would be less confusing? Maybe someone else has a better idea.

This seems like a reasonable topic for the operator-framework email list.

Michael



On Wed, Oct 6, 2021 at 4:47 PM Matt Farina <matt@...> wrote:
Thanks for providing clarification with…

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

I think there are a couple problems here, though.

  1. People are taking the levels as Helm stand alone vs operators in general. This has come up in numerous conversations. It appears to be a point of confusion. How can we work to clear that up?
  2. The community has taken the model far further than Operator SDK based. The operator working group included it as a general thing in their white paper on operators. This model is being applied outside its intended space, as you have said the space is. How can the communication be updated to help clear that up?
  3. The OperatorHub website uses the model and says it’s for operators. It does not clarify that it’s for Operator SDK based operators. There are many non-Operator SDK based operators. This, I think, leads to the confusion in messaging.

Do you see why people are confused on the topic?

- Matt Farina


On Oct 6, 2021, at 4:10 PM, Michael Hrivnak <mhrivnak@...> wrote:

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 that operator-sdk can help you make. The capability levels *do not* draw a comparison of operators vs. helm.

For very brief background: the operator-sdk enables you to use a helm chart as the basis for a simple operator, with no coding required. You get a CRD to represent your operand, and a controller that applies the chart during reconciliation. That can be useful, but the resulting operator is limited to whatever the chart can do.

Michael

On Wed, Oct 6, 2021 at 3:07 PM Matt Farina <matt@...> wrote:
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 features? The answer is obviously no because they solve two different problems and can be used to compliment each other. Ansible regularly uses RPMs and Debian packages.

Helm is a package manager like apt or yum. It is used to install, upgrade, and uninstall packages.

Operators are more complex. To quote the original definition of operators…

An Operator is an application-specific controller that extends the Kubernetes API to create, configure, and manage instances of complex stateful applications on behalf of a Kubernetes user. It builds upon the basic Kubernetes resource and controller concepts but includes domain or application-specific knowledge to automate common tasks.

It’s about managing instances of applications. This reminds me of something like ansible or Chef. It’s more like Chef conceptually because Chef did things with agents and a pull based model.

These two can complement each other. An operator can use Helm and charts for the install, upgrade, and uninstall elements. In fact, some do.

So, I would not expect to have Helm support operator capabilities because they solve different problems. The fact that they’re compared that way is marketing rather than technical.

- Matt Farina

On Oct 6, 2021, at 11:31 AM, Paul C <username.taken@...> wrote:

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 much there that a well written Helm Chart can't/won't do.  

* Full lifecycle -  Assuming the app is fairly cloud native the kube controllers (deployment/statefulset/etc) will manage most failure recoveries, and jobs/cronjobs for backups, and helm hooks for assisting with upgrade tasks.  

* Deep insight - this isn't really an operator thing, except for the fact an operator can automatically set up prometheus (and similar) servicemonitors/alerts etc, all things you can do with your helm charts

* Auto Pilot - most of the auto-scaling can be done with kube HPA/VPA and similar techniques, I've seens cronjobs used to do scheduled scaling as well, abnormality detection etc can be done as easily with a sidecar application as it can with an operator.



On Wed, Oct 6, 2021 at 3:53 AM Anil Kumar <anil181@...> wrote:
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 through this page we see that Helm does not support complete Operator capability level:https://sdk.operatorframework.io/docs/overview/operator-capabilities/

Could someone let me know if Helm has a plan to support the complete Operator maturity level on the roadmap as we see with Ansible and Go.

Thanks and Regards,
Anil Kumar









-- 
Michael Hrivnak

Senior Principal Software Engineer, RHCE 
Red Hat



--

Michael Hrivnak

Senior Principal Software Engineer, RHCE 

Red Hat
Re: Does Helm has a plan to support the complete Operator maturity level?

Matt Farina
 

Thanks for providing clarification with…

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

I think there are a couple problems here, though.

  1. People are taking the levels as Helm stand alone vs operators in general. This has come up in numerous conversations. It appears to be a point of confusion. How can we work to clear that up?
  2. The community has taken the model far further than Operator SDK based. The operator working group included it as a general thing in their white paper on operators. This model is being applied outside its intended space, as you have said the space is. How can the communication be updated to help clear that up?
  3. The OperatorHub website uses the model and says it’s for operators. It does not clarify that it’s for Operator SDK based operators. There are many non-Operator SDK based operators. This, I think, leads to the confusion in messaging.

Do you see why people are confused on the topic?

- Matt Farina


On Oct 6, 2021, at 4:10 PM, Michael Hrivnak <mhrivnak@...> wrote:

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 that operator-sdk can help you make. The capability levels *do not* draw a comparison of operators vs. helm.

For very brief background: the operator-sdk enables you to use a helm chart as the basis for a simple operator, with no coding required. You get a CRD to represent your operand, and a controller that applies the chart during reconciliation. That can be useful, but the resulting operator is limited to whatever the chart can do.

Michael

On Wed, Oct 6, 2021 at 3:07 PM Matt Farina <matt@...> wrote:
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 features? The answer is obviously no because they solve two different problems and can be used to compliment each other. Ansible regularly uses RPMs and Debian packages.

Helm is a package manager like apt or yum. It is used to install, upgrade, and uninstall packages.

Operators are more complex. To quote the original definition of operators…

An Operator is an application-specific controller that extends the Kubernetes API to create, configure, and manage instances of complex stateful applications on behalf of a Kubernetes user. It builds upon the basic Kubernetes resource and controller concepts but includes domain or application-specific knowledge to automate common tasks.

It’s about managing instances of applications. This reminds me of something like ansible or Chef. It’s more like Chef conceptually because Chef did things with agents and a pull based model.

These two can complement each other. An operator can use Helm and charts for the install, upgrade, and uninstall elements. In fact, some do.

So, I would not expect to have Helm support operator capabilities because they solve different problems. The fact that they’re compared that way is marketing rather than technical.

- Matt Farina

On Oct 6, 2021, at 11:31 AM, Paul C <username.taken@...> wrote:

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 much there that a well written Helm Chart can't/won't do.  

* Full lifecycle -  Assuming the app is fairly cloud native the kube controllers (deployment/statefulset/etc) will manage most failure recoveries, and jobs/cronjobs for backups, and helm hooks for assisting with upgrade tasks.  

* Deep insight - this isn't really an operator thing, except for the fact an operator can automatically set up prometheus (and similar) servicemonitors/alerts etc, all things you can do with your helm charts

* Auto Pilot - most of the auto-scaling can be done with kube HPA/VPA and similar techniques, I've seens cronjobs used to do scheduled scaling as well, abnormality detection etc can be done as easily with a sidecar application as it can with an operator.



On Wed, Oct 6, 2021 at 3:53 AM Anil Kumar <anil181@...> wrote:
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 through this page we see that Helm does not support complete Operator capability level:https://sdk.operatorframework.io/docs/overview/operator-capabilities/

Could someone let me know if Helm has a plan to support the complete Operator maturity level on the roadmap as we see with Ansible and Go.

Thanks and Regards,
Anil Kumar









-- 
Michael Hrivnak

Senior Principal Software Engineer, RHCE 
Red Hat

?
smime.p7s

Re: Does Helm has a plan to support the complete Operator maturity level?

Devdatta Kulkarni
 

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 Operator is typically developed if you want to perform certain application specific tasks in Kubernetes-native manner. We have seen a number of DevOps teams start out first by packaging their application as a Helm chart. They may use popular community Operators on their cluster (such as cert manager, Prometheus etc.) and create their custom resources through the Helm chart. Lot of times this arrangement is sufficient and does not require a brand-new Operator development. If you still see the need to perform certain application specific configurations through Kubernetes API, then you can explore writing an Operator for your application.

Going a step further beyond understanding the difference between an Operator and Helm, there are also some Operators in the community that are written to automate distribution and management of Helm charts, such as the Helm Operator from Operator SDK and our project KubePlus (https://github.com/cloud-ark/kubeplus). These Operators essentially wrap a Kubernetes-native API around Helm charts. The need for such Operators arises in situations when there are multiple teams or personas involved, such as provider of the application and consumer of the application, - say a DevOps team is looking to deliver an application as a service to their product team. For such a service-based delivery model, the typical day 2 operations include things like - ability to apply resource policies at application-level, ability to troubleshoot the deployed applications, ability to track resource consumption per application instance, etc. Generic Operators like KubePlus can help with these operations. If you are looking for day 2 operations such as the above, you can check out KubePlus.

-Devdatta

From: cncf-helm@... on behalf of Matt Farina
Sent: Wednesday, October 6, 2021 2:04 PM
To: Anil Kumar
Cc: cncf-helm@...; Paul C
Subject: Re: [cncf-helm] Does Helm has a plan to support the complete Operator maturity level?

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 features? The answer is obviously no because they solve two different problems and can be used to compliment each other. Ansible regularly uses RPMs and Debian packages.

Helm is a package manager like apt or yum. It is used to install, upgrade, and uninstall packages.

Operators are more complex. To quote the original definition of operators…

An Operator is an application-specific controller that extends the Kubernetes API to create, configure, and manage instances of complex stateful applications on behalf of a Kubernetes user. It builds upon the basic Kubernetes resource and controller concepts but includes domain or application-specific knowledge to automate common tasks.

It’s about managing instances of applications. This reminds me of something like ansible or Chef. It’s more like Chef conceptually because Chef did things with agents and a pull based model.

These two can complement each other. An operator can use Helm and charts for the install, upgrade, and uninstall elements. In fact, some do.

So, I would not expect to have Helm support operator capabilities because they solve different problems. The fact that they’re compared that way is marketing rather than technical.

- Matt Farina

On Oct 6, 2021, at 11:31 AM, Paul C <username.taken@...> wrote:

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 much there that a well written Helm Chart can't/won't do.  

* Full lifecycle -  Assuming the app is fairly cloud native the kube controllers (deployment/statefulset/etc) will manage most failure recoveries, and jobs/cronjobs for backups, and helm hooks for assisting with upgrade tasks.  

* Deep insight - this isn't really an operator thing, except for the fact an operator can automatically set up prometheus (and similar) servicemonitors/alerts etc, all things you can do with your helm charts

* Auto Pilot - most of the auto-scaling can be done with kube HPA/VPA and similar techniques, I've seens cronjobs used to do scheduled scaling as well, abnormality detection etc can be done as easily with a sidecar application as it can with an operator.



On Wed, Oct 6, 2021 at 3:53 AM Anil Kumar <anil181@...> wrote:
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 through this page we see that Helm does not support complete Operator capability level:https://sdk.operatorframework.io/docs/overview/operator-capabilities/

Could someone let me know if Helm has a plan to support the complete Operator maturity level on the roadmap as we see with Ansible and Go.

Thanks and Regards,
Anil Kumar
Re: Does Helm has a plan to support the complete Operator maturity level?

Fox, Kevin M <Kevin.Fox@...>
 

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 operator specific.

That being said, the view of cloud native app packaging needing these kinds of capabilities, and easy description thereof is a good thing. Maybe a workgroup under the CNCF could form (or one already exists) to standardize some terminology and encourage its use? Anyone interested in doing that?

Thanks,
Kevin

________________________________________
From: cncf-helm@lists.cncf.io <cncf-helm@lists.cncf.io> on behalf of Paul C <username.taken@gmail.com>
Sent: Wednesday, October 6, 2021 8:31 AM
To: Anil Kumar
Cc: cncf-helm@lists.cncf.io
Subject: Re: [cncf-helm] Does Helm has a plan to support the complete Operator maturity level?

Check twice before you click! This email originated from outside PNNL.

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 much there that a well written Helm Chart can't/won't do.

* Full lifecycle - Assuming the app is fairly cloud native the kube controllers (deployment/statefulset/etc) will manage most failure recoveries, and jobs/cronjobs for backups, and helm hooks for assisting with upgrade tasks.

* Deep insight - this isn't really an operator thing, except for the fact an operator can automatically set up prometheus (and similar) servicemonitors/alerts etc, all things you can do with your helm charts

* Auto Pilot - most of the auto-scaling can be done with kube HPA/VPA and similar techniques, I've seens cronjobs used to do scheduled scaling as well, abnormality detection etc can be done as easily with a sidecar application as it can with an operator.



On Wed, Oct 6, 2021 at 3:53 AM Anil Kumar <anil181@gmail.com<mailto:anil181@gmail.com>> wrote:
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 through this page we see that Helm does not support complete Operator capability level:https://sdk.operatorframework.io/docs/overview/operator-capabilities/<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsdk.operatorframework.io%2Fdocs%2Foverview%2Foperator-capabilities%2F&data=04%7C01%7CKevin.Fox%40pnnl.gov%7C0268ce034cde496114e308d988de8670%7Cd6faa5f90ae240338c0130048a38deeb%7C0%7C0%7C637691312500956290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2HAcTqHjb84hpT00bwJ10unC1B4aCUNt44a5JBkafug%3D&reserved=0>

Could someone let me know if Helm has a plan to support the complete Operator maturity level on the roadmap as we see with Ansible and Go.

Thanks and Regards,
Anil Kumar
Re: Does Helm has a plan to support the complete Operator maturity level?

Fox, Kevin M <Kevin.Fox@...>
 

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 combination of the "ansible based operator sdk" and helm.

Thanks,
Kevin

________________________________________
From: cncf-helm@lists.cncf.io <cncf-helm@lists.cncf.io> on behalf of Anil Kumar <anil181@gmail.com>
Sent: Wednesday, October 6, 2021 1:52 AM
To: cncf-helm@lists.cncf.io
Subject: [cncf-helm] Does Helm has a plan to support the complete Operator maturity level?

Check twice before you click! This email originated from outside PNNL.

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 through this page we see that Helm does not support complete Operator capability level:https://sdk.operatorframework.io/docs/overview/operator-capabilities/<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsdk.operatorframework.io%2Fdocs%2Foverview%2Foperator-capabilities%2F&data=04%7C01%7CKevin.Fox%40pnnl.gov%7C24354ce801a448b2a2fe08d988a6d126%7Cd6faa5f90ae240338c0130048a38deeb%7C0%7C0%7C637691072956766292%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=q4fizH5nDmOI8a4ex06ykUIrNT3aPInNvTYxkEVkrtM%3D&reserved=0>

Could someone let me know if Helm has a plan to support the complete Operator maturity level on the roadmap as we see with Ansible and Go.

Thanks and Regards,
Anil Kumar
Re: Does Helm has a plan to support the complete Operator maturity level?

Michael Hrivnak
 

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 that operator-sdk can help you make. The capability levels *do not* draw a comparison of operators vs. helm.

For very brief background: the operator-sdk enables you to use a helm chart as the basis for a simple operator, with no coding required. You get a CRD to represent your operand, and a controller that applies the chart during reconciliation. That can be useful, but the resulting operator is limited to whatever the chart can do.

Michael

On Wed, Oct 6, 2021 at 3:07 PM Matt Farina <matt@...> wrote:
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 features? The answer is obviously no because they solve two different problems and can be used to compliment each other. Ansible regularly uses RPMs and Debian packages.

Helm is a package manager like apt or yum. It is used to install, upgrade, and uninstall packages.

Operators are more complex. To quote the original definition of operators…

An Operator is an application-specific controller that extends the Kubernetes API to create, configure, and manage instances of complex stateful applications on behalf of a Kubernetes user. It builds upon the basic Kubernetes resource and controller concepts but includes domain or application-specific knowledge to automate common tasks.

It’s about managing instances of applications. This reminds me of something like ansible or Chef. It’s more like Chef conceptually because Chef did things with agents and a pull based model.

These two can complement each other. An operator can use Helm and charts for the install, upgrade, and uninstall elements. In fact, some do.

So, I would not expect to have Helm support operator capabilities because they solve different problems. The fact that they’re compared that way is marketing rather than technical.

- Matt Farina

On Oct 6, 2021, at 11:31 AM, Paul C <username.taken@...> wrote:

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 much there that a well written Helm Chart can't/won't do.  

* Full lifecycle -  Assuming the app is fairly cloud native the kube controllers (deployment/statefulset/etc) will manage most failure recoveries, and jobs/cronjobs for backups, and helm hooks for assisting with upgrade tasks.  

* Deep insight - this isn't really an operator thing, except for the fact an operator can automatically set up prometheus (and similar) servicemonitors/alerts etc, all things you can do with your helm charts

* Auto Pilot - most of the auto-scaling can be done with kube HPA/VPA and similar techniques, I've seens cronjobs used to do scheduled scaling as well, abnormality detection etc can be done as easily with a sidecar application as it can with an operator.



On Wed, Oct 6, 2021 at 3:53 AM Anil Kumar <anil181@...> wrote:
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 through this page we see that Helm does not support complete Operator capability level:https://sdk.operatorframework.io/docs/overview/operator-capabilities/

Could someone let me know if Helm has a plan to support the complete Operator maturity level on the roadmap as we see with Ansible and Go.

Thanks and Regards,
Anil Kumar







--

Michael Hrivnak

Senior Principal Software Engineer, RHCE 

Red Hat
Re: Does Helm has a plan to support the complete Operator maturity level?

Matt Farina
 

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 features? The answer is obviously no because they solve two different problems and can be used to compliment each other. Ansible regularly uses RPMs and Debian packages.

Helm is a package manager like apt or yum. It is used to install, upgrade, and uninstall packages.

Operators are more complex. To quote the original definition of operators…

An Operator is an application-specific controller that extends the Kubernetes API to create, configure, and manage instances of complex stateful applications on behalf of a Kubernetes user. It builds upon the basic Kubernetes resource and controller concepts but includes domain or application-specific knowledge to automate common tasks.

It’s about managing instances of applications. This reminds me of something like ansible or Chef. It’s more like Chef conceptually because Chef did things with agents and a pull based model.

These two can complement each other. An operator can use Helm and charts for the install, upgrade, and uninstall elements. In fact, some do.

So, I would not expect to have Helm support operator capabilities because they solve different problems. The fact that they’re compared that way is marketing rather than technical.

- Matt Farina

On Oct 6, 2021, at 11:31 AM, Paul C <username.taken@...> wrote:

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 much there that a well written Helm Chart can't/won't do.  

* Full lifecycle -  Assuming the app is fairly cloud native the kube controllers (deployment/statefulset/etc) will manage most failure recoveries, and jobs/cronjobs for backups, and helm hooks for assisting with upgrade tasks.  

* Deep insight - this isn't really an operator thing, except for the fact an operator can automatically set up prometheus (and similar) servicemonitors/alerts etc, all things you can do with your helm charts

* Auto Pilot - most of the auto-scaling can be done with kube HPA/VPA and similar techniques, I've seens cronjobs used to do scheduled scaling as well, abnormality detection etc can be done as easily with a sidecar application as it can with an operator.



On Wed, Oct 6, 2021 at 3:53 AM Anil Kumar <anil181@...> wrote:
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 through this page we see that Helm does not support complete Operator capability level:https://sdk.operatorframework.io/docs/overview/operator-capabilities/

Could someone let me know if Helm has a plan to support the complete Operator maturity level on the roadmap as we see with Ansible and Go.

Thanks and Regards,
Anil Kumar





?
smime.p7s

Re: Does Helm has a plan to support the complete Operator maturity level?

Paul C
 

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 much there that a well written Helm Chart can't/won't do.  

* Full lifecycle -  Assuming the app is fairly cloud native the kube controllers (deployment/statefulset/etc) will manage most failure recoveries, and jobs/cronjobs for backups, and helm hooks for assisting with upgrade tasks.  

* Deep insight - this isn't really an operator thing, except for the fact an operator can automatically set up prometheus (and similar) servicemonitors/alerts etc, all things you can do with your helm charts

* Auto Pilot - most of the auto-scaling can be done with kube HPA/VPA and similar techniques, I've seens cronjobs used to do scheduled scaling as well, abnormality detection etc can be done as easily with a sidecar application as it can with an operator.



On Wed, Oct 6, 2021 at 3:53 AM Anil Kumar <anil181@...> wrote:
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 through this page we see that Helm does not support complete Operator capability level:https://sdk.operatorframework.io/docs/overview/operator-capabilities/

Could someone let me know if Helm has a plan to support the complete Operator maturity level on the roadmap as we see with Ansible and Go.

Thanks and Regards,
Anil Kumar
Does Helm has a plan to support the complete Operator maturity level?

Anil Kumar <anil181@...>
 

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 through this page we see that Helm does not support complete Operator capability level:https://sdk.operatorframework.io/docs/overview/operator-capabilities/

Could someone let me know if Helm has a plan to support the complete Operator maturity level on the roadmap as we see with Ansible and Go.

Thanks and Regards,
Anil Kumar
Re: [EXTERNAL] Re: [cncf-helm] Self nomination to help maintain helm/helm

Matt Butcher
 

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 core maintainer's list in order to respect confidentiality).

This was my mistake for not noticing right at the outset, and I apologize for that.

Matt Farina and I have consulted the governance doc, and we believe we can count these votes under the particular circumstances. But that's a loophole we'll close in a future iteration of the governance doc.

Again, super sorry for the confusion.

Matt

From: cncf-helm@... <cncf-helm@...> on behalf of Reinhard Nägele via lists.cncf.io <unguiculus=gmail.com@...>
Sent: Monday, September 20, 2021 11:25 PM
To: cncf-helm@... <cncf-helm@...>
Cc: Scott Rigby <scott@...>
Subject: Re: [EXTERNAL] Re: [cncf-helm] Self nomination to help maintain helm/helm
 
+1 🎉👏

Am 21.09.2021 um 00:43 schrieb Matt Butcher via lists.cncf.io <matt.butcher=microsoft.com@...>:


+1 for Scott
From: cncf-helm@... <cncf-helm@...> on behalf of Carlos Tadeu Panato Jr via lists.cncf.io <ctadeu=gmail.com@...>
Sent: Friday, September 17, 2021 1:40 AM
To: Scott Rigby <scott@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: [EXTERNAL] Re: [cncf-helm] Self nomination to help maintain helm/helm
 
You don't often get email from ctadeu=gmail.com@.... Learn why this is important
+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 with helm/helm repo maintainer duties for a while now.
If I understand the Triage Maintainer HIP and Governance correctly, I would only need to self nominate as a core maintainer to be able to help with both of these. I'm I need to self nominate for the triage maintainer role too, please lmk 🙂

I've been on the Helm team since 2017. I'm a Helm Org maintainer, and Charts maintainer (the team who oversaw the now archived helm/charts, as who continues to maintain charts automation and tooling such as helm/chart-testing, helm/chart-releaser, and the Helm Charts GitHub actions in this working demo). However while I have contributed a bit to Helm core in the past, it's been a while and I have never been a maintainer of the helm/helm repo.

I'm currently on the DX team at Weaveworks, and help maintain other CNCF community projects such as Flux, and OpenGitOps, and co-chair the GitOps Working Group under App Delivery TAG.

In addition to other helm/helm duties, I'd like to help us keep prioritizing the Helm SDK as the Helm project continues to evolve. I've been spending time with k8s controller-runtime as a step toward helping more with the Flux Helm Controller, which is an example of a project that makes full use of the Helm's SDK. So I will already be a more active SDK end user, as well as be more active helping support others who use Helm's SDK.

I'm finally in a role that can support me doing some of this, and happy to help with helm/helm maintenance however I can if current maintainers think it makes sense.
 
 
xo, Scott

--

Scott Rigby
Developer Experience, Weaveworks
Re: Self nomination to help maintain helm/helm

Josh Dolitsky
 

+1 !

On Wed, Sep 22, 2021 at 9:46 AM Adam Reese via lists.cncf.io <adam.reese=microsoft.com@...> wrote:
+1

Re: Self nomination to help maintain helm/helm

Adam Reese
 

+1
Re: [EXTERNAL] Re: [cncf-helm] Self nomination to help maintain helm/helm

Reinhard Nägele
 

+1 🎉👏

Am 21.09.2021 um 00:43 schrieb Matt Butcher via lists.cncf.io <matt.butcher=microsoft.com@...>:


+1 for Scott
From: cncf-helm@... <cncf-helm@...> on behalf of Carlos Tadeu Panato Jr via lists.cncf.io <ctadeu=gmail.com@...>
Sent: Friday, September 17, 2021 1:40 AM
To: Scott Rigby <scott@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: [EXTERNAL] Re: [cncf-helm] Self nomination to help maintain helm/helm
 
You don't often get email from ctadeu=gmail.com@.... Learn why this is important
+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 with helm/helm repo maintainer duties for a while now.
If I understand the Triage Maintainer HIP and Governance correctly, I would only need to self nominate as a core maintainer to be able to help with both of these. I'm I need to self nominate for the triage maintainer role too, please lmk 🙂

I've been on the Helm team since 2017. I'm a Helm Org maintainer, and Charts maintainer (the team who oversaw the now archived helm/charts, as who continues to maintain charts automation and tooling such as helm/chart-testing, helm/chart-releaser, and the Helm Charts GitHub actions in this working demo). However while I have contributed a bit to Helm core in the past, it's been a while and I have never been a maintainer of the helm/helm repo.

I'm currently on the DX team at Weaveworks, and help maintain other CNCF community projects such as Flux, and OpenGitOps, and co-chair the GitOps Working Group under App Delivery TAG.

In addition to other helm/helm duties, I'd like to help us keep prioritizing the Helm SDK as the Helm project continues to evolve. I've been spending time with k8s controller-runtime as a step toward helping more with the Flux Helm Controller, which is an example of a project that makes full use of the Helm's SDK. So I will already be a more active SDK end user, as well as be more active helping support others who use Helm's SDK.

I'm finally in a role that can support me doing some of this, and happy to help with helm/helm maintenance however I can if current maintainers think it makes sense.
 
 
xo, Scott

--

Scott Rigby
Developer Experience, Weaveworks
Re: [EXTERNAL] Re: [cncf-helm] Self nomination to help maintain helm/helm

Matt Butcher
 

+1 for Scott

From: cncf-helm@... <cncf-helm@...> on behalf of Carlos Tadeu Panato Jr via lists.cncf.io <ctadeu=gmail.com@...>
Sent: Friday, September 17, 2021 1:40 AM
To: Scott Rigby <scott@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: [EXTERNAL] Re: [cncf-helm] Self nomination to help maintain helm/helm
 
You don't often get email from ctadeu=gmail.com@.... Learn why this is important
+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 with helm/helm repo maintainer duties for a while now.
If I understand the Triage Maintainer HIP and Governance correctly, I would only need to self nominate as a core maintainer to be able to help with both of these. I'm I need to self nominate for the triage maintainer role too, please lmk 🙂

I've been on the Helm team since 2017. I'm a Helm Org maintainer, and Charts maintainer (the team who oversaw the now archived helm/charts, as who continues to maintain charts automation and tooling such as helm/chart-testing, helm/chart-releaser, and the Helm Charts GitHub actions in this working demo). However while I have contributed a bit to Helm core in the past, it's been a while and I have never been a maintainer of the helm/helm repo.

I'm currently on the DX team at Weaveworks, and help maintain other CNCF community projects such as Flux, and OpenGitOps, and co-chair the GitOps Working Group under App Delivery TAG.

In addition to other helm/helm duties, I'd like to help us keep prioritizing the Helm SDK as the Helm project continues to evolve. I've been spending time with k8s controller-runtime as a step toward helping more with the Flux Helm Controller, which is an example of a project that makes full use of the Helm's SDK. So I will already be a more active SDK end user, as well as be more active helping support others who use Helm's SDK.

I'm finally in a role that can support me doing some of this, and happy to help with helm/helm maintenance however I can if current maintainers think it makes sense.
 
 
xo, Scott

--

Scott Rigby
Developer Experience, Weaveworks
Re: Self nomination to help maintain helm/helm

Jeff Billimek
 

+1

Scott has been very helpful with the charts testing/releasing features and associated GitHub actions!
Re: Self nomination to help maintain helm/helm

Martin Hickey
 

+1

Regards,
Martin
 

----- Original message -----
From: "Scott Rigby" <scott@...>
Sent by: cncf-helm@...
To: cncf-helm@...
Cc:
Subject: [EXTERNAL] [cncf-helm] Self nomination to help maintain helm/helm
Date: Thu, Sep 16, 2021 8:08 PM
 
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 with helm/helm repo maintainer duties for a while ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
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 with helm/helm repo maintainer duties for a while now.
If I understand the Triage Maintainer HIP and Governance correctly, I would only need to self nominate as a core maintainer to be able to help with both of these. I'm I need to self nominate for the triage maintainer role too, please lmk 🙂

I've been on the Helm team since 2017. I'm a Helm Org maintainer, and Charts maintainer (the team who oversaw the now archived helm/charts, as who continues to maintain charts automation and tooling such as helm/chart-testing, helm/chart-releaser, and the Helm Charts GitHub actions in this working demo). However while I have contributed a bit to Helm core in the past, it's been a while and I have never been a maintainer of the helm/helm repo.

I'm currently on the DX team at Weaveworks, and help maintain other CNCF community projects such as Flux, and OpenGitOps, and co-chair the GitOps Working Group under App Delivery TAG.

In addition to other helm/helm duties, I'd like to help us keep prioritizing the Helm SDK as the Helm project continues to evolve. I've been spending time with k8s controller-runtime as a step toward helping more with the Flux Helm Controller, which is an example of a project that makes full use of the Helm's SDK. So I will already be a more active SDK end user, as well as be more active helping support others who use Helm's SDK.

I'm finally in a role that can support me doing some of this, and happy to help with helm/helm maintenance however I can if current maintainers think it makes sense.
 
 
xo, Scott
 

--

Scott Rigby
Developer Experience, Weaveworks
 
Re: Self nomination to help maintain helm/helm

Carlos Tadeu Panato Jr
 

+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 with helm/helm repo maintainer duties for a while now.
If I understand the Triage Maintainer HIP and Governance correctly, I would only need to self nominate as a core maintainer to be able to help with both of these. I'm I need to self nominate for the triage maintainer role too, please lmk 🙂

I've been on the Helm team since 2017. I'm a Helm Org maintainer, and Charts maintainer (the team who oversaw the now archived helm/charts, as who continues to maintain charts automation and tooling such as helm/chart-testing, helm/chart-releaser, and the Helm Charts GitHub actions in this working demo). However while I have contributed a bit to Helm core in the past, it's been a while and I have never been a maintainer of the helm/helm repo.

I'm currently on the DX team at Weaveworks, and help maintain other CNCF community projects such as Flux, and OpenGitOps, and co-chair the GitOps Working Group under App Delivery TAG.

In addition to other helm/helm duties, I'd like to help us keep prioritizing the Helm SDK as the Helm project continues to evolve. I've been spending time with k8s controller-runtime as a step toward helping more with the Flux Helm Controller, which is an example of a project that makes full use of the Helm's SDK. So I will already be a more active SDK end user, as well as be more active helping support others who use Helm's SDK.

I'm finally in a role that can support me doing some of this, and happy to help with helm/helm maintenance however I can if current maintainers think it makes sense.
 
 
xo, Scott

--

Scott Rigby
Developer Experience, Weaveworks
Self nomination to help maintain helm/helm

Scott Rigby
 

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 with helm/helm repo maintainer duties for a while now.
If I understand the Triage Maintainer HIP and Governance correctly, I would only need to self nominate as a core maintainer to be able to help with both of these. I'm I need to self nominate for the triage maintainer role too, please lmk 🙂

I've been on the Helm team since 2017. I'm a Helm Org maintainer, and Charts maintainer (the team who oversaw the now archived helm/charts, as who continues to maintain charts automation and tooling such as helm/chart-testing, helm/chart-releaser, and the Helm Charts GitHub actions in this working demo). However while I have contributed a bit to Helm core in the past, it's been a while and I have never been a maintainer of the helm/helm repo.

I'm currently on the DX team at Weaveworks, and help maintain other CNCF community projects such as Flux, and OpenGitOps, and co-chair the GitOps Working Group under App Delivery TAG.

In addition to other helm/helm duties, I'd like to help us keep prioritizing the Helm SDK as the Helm project continues to evolve. I've been spending time with k8s controller-runtime as a step toward helping more with the Flux Helm Controller, which is an example of a project that makes full use of the Helm's SDK. So I will already be a more active SDK end user, as well as be more active helping support others who use Helm's SDK.

I'm finally in a role that can support me doing some of this, and happy to help with helm/helm maintenance however I can if current maintainers think it makes sense.
 
 
xo, Scott

--

Scott Rigby
Developer Experience, Weaveworks
Triage Maintainer Self Nomination: Allen Bai

Allen Bai
 

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 Helm integration
within OpenShift. I've been attending weekly Helm developer calls for
~3 months since I joined the Helm team at Red Hat on May 25th.
Although relatively new to `helm/helm` and Go, I am actively learning
and catching up. I would like this opportunity to work with other Helm
maintainers to triage and review code and contribute to the Helm
community.

Doc references:
- Triage Maintainer HIP:
https://github.com/helm/community/blob/main/hips/hip-0014.md
- Governance Documentation:
https://github.com/helm/community/blob/main/governance/governance.md

Github: https://github.com/zonggen

Best regards,
Allen Bai
[HIP] cascade option for uninstall and upgrade commands

Péter Laukó <peter.lauko@...>
 

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 dependent objects unconditionally. This is the preferred behaviour for most of the time, but I think it would make sense to make it configurable. For example we set owner references between custom resources (default configuration pieces provided by our application and their user overrides) and most of the time we would like them to come and go together. However if an upgrade fails, the owned objects (user overrides) should be kept in place, and being able to turn off cascading would make fixing the failed release easier.

Please let me know if you think this idea makes sense and I'm happy to prepare a formal proposal and provide the patch.

Best,
Peter
1 - 20 of 416