Date   

Re: Nomination for Helm Org maintainer: Karen Chu

Ronan Flynn-Curran
 

I agree, +1 to add Karen


Re: Triage Maintainer Self Nomination: Joe Julian

Matt Butcher
 

Congratulations, Joe!


From: cncf-helm@... <cncf-helm@...> on behalf of Marc Khouzam via lists.cncf.io <marc.khouzam=gmail.com@...>
Sent: Thursday, January 6, 2022 11:02:42 AM
To: Joe Julian <me@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] Triage Maintainer Self Nomination: Joe Julian
 
Thank you for your patience Joe.  You have now obtained all the necessary votes to become Helm's latest triage maintainer! 👏
Actually, you got the votes last month but I only noticed now (thanks go to Bridget for bringing it up).

We will be onboarding you shortly (accesses and such).

Thanks for volunteering to help the Helm project!

Marc


On Fri, Oct 29, 2021 at 5:33 PM Marc Khouzam <marc.khouzam@...> wrote:
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 over.

Thanks again

Marc

On Thu, Oct 28, 2021 at 13:00 Joe Julian <me@...> wrote:
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
maintainer doing triage, and have been helping on issues, where I can,
without being official. I would love to have this opportunity to
contribute more.

GitHub: https://github.com/joejulian
Twitter: https://twitter.com/JoeCyberGuru







Re: Triage Maintainer Self Nomination: Joe Julian

Marc Khouzam
 

Thank you for your patience Joe.  You have now obtained all the necessary votes to become Helm's latest triage maintainer! 👏
Actually, you got the votes last month but I only noticed now (thanks go to Bridget for bringing it up).

We will be onboarding you shortly (accesses and such).

Thanks for volunteering to help the Helm project!

Marc


On Fri, Oct 29, 2021 at 5:33 PM Marc Khouzam <marc.khouzam@...> wrote:
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 over.

Thanks again

Marc

On Thu, Oct 28, 2021 at 13:00 Joe Julian <me@...> wrote:
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
maintainer doing triage, and have been helping on issues, where I can,
without being official. I would love to have this opportunity to
contribute more.

GitHub: https://github.com/joejulian
Twitter: https://twitter.com/JoeCyberGuru







Re: New Idea proposal vetting - adding hook logs output

bez625@...
 

Hi all,

It's been well over a month since we addressed Matt's feedback on the PR and we've tried to make contact multiple times via the github review, slack and this mailing list all of which have been completely ignored.... Is there something more we need to be doing to get this reviewed? Or at least acknowledged?

Thanks
Chris 


Re: New Idea proposal vetting - adding hook logs output

bez625@...
 

Hi all,

We have been waiting for some time now without response - is there anything we can do to progress this PR?

I believe there is appetite for this feature in the community too so it would be good if we could at least get an update...

Thanks
Chris 


Re: Nomination for Helm Org maintainer: Karen Chu

Marc Khouzam
 

I guess I was too eager 😇
I should wait for the official vote to open

On Sat, Dec 18, 2021 at 15:28 Marc Khouzam via lists.cncf.io <marc.khouzam=gmail.com@...> wrote:
+1
Karen would be a great addition in my opinion!

On Thu, Dec 16, 2021 at 19:02 Karen Chu <chu.karen.h@...> wrote:
I accept the nomination!! 


Re: Nomination for Helm Org maintainer: Karen Chu

Marc Khouzam
 

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

On Thu, Dec 16, 2021 at 19:02 Karen Chu <chu.karen.h@...> wrote:
I accept the nomination!! 


Re: Nomination for Helm Org maintainer: Karen Chu

Karen Chu
 

I accept the nomination!! 


Nomination for Helm Org maintainer: Karen Chu

Bridget Kromhout
 

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 https://github.com/helm/community/blob/main/governance/governance.md#helm-org-maintainers, I am nominating Karen Chu.

Karen has been active on the Helm project since its inception at Deis, and her community management role was formally recognized in 2019: https://helm.sh/blog/2019-11-11-community-management/

When I look at the responsibilities of the org maintainers, I think of Karen. She has a clear picture of the mission, vision, values, and scope of Helm. She is key to managing and messaging the brand and identity, and she has experience in broader contexts with handling escalations and resolving conflicts. I am confident that Karen will be able to guide Helm with her unique perspective and keep it on track as a healthy graduated CNCF project. As we all know, keeping a project on track requires much attention to these details, and I think Karen will meet the challenge handily.

I look forward to Karen accepting this nomination, after which we can call a vote.

--
Bridget Kromhout


Re: New Idea proposal vetting - adding hook logs output

bez625@...
 

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 reviewed that would be very much appreciated https://github.com/helm/helm/pull/10309

Thanks!
Chris 


Re: Idea proposal: --reuse-values specifying a release version

zouhair hamza
 

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



Le mar. 30 nov. 2021 à 16:27, Antoine Sauray <antoine.sauray@...> a écrit :
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 deployments enabled using a boolean value in our helm release. When releasing a new version, the deployment is gradually rolled out to our users.

There may be some situations where we still have to rollback though. In that scenario, the `helm rollback` command does not work for us because it still contains the boolean value that was used to gradually rollout our deployment. The consequence is that the rollback goes through a canary again, even though we might actually be facing a production issue.

We thought of using the `helm upgrade` command with `—reuse-values` and `—set` but we only have access to the latest revision.

We think it would be interesting if we could specify the version of the release we want to use the values in the `—reuse-values` command, or if we could upgrade values with a command like `—set` in the `helm rollback` command.

What do you think ? Do you think one of the two alternatives is better ? Or maybe none match your expectations for the helm project ?

Regards,
Antoine Sauray





Idea proposal: --reuse-values specifying a release version

Antoine Sauray <antoine.sauray@...>
 

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 deployments enabled using a boolean value in our helm release. When releasing a new version, the deployment is gradually rolled out to our users.

There may be some situations where we still have to rollback though. In that scenario, the `helm rollback` command does not work for us because it still contains the boolean value that was used to gradually rollout our deployment. The consequence is that the rollback goes through a canary again, even though we might actually be facing a production issue.

We thought of using the `helm upgrade` command with `—reuse-values` and `—set` but we only have access to the latest revision.

We think it would be interesting if we could specify the version of the release we want to use the values in the `—reuse-values` command, or if we could upgrade values with a command like `—set` in the `helm rollback` command.

What do you think ? Do you think one of the two alternatives is better ? Or maybe none match your expectations for the helm project ?

Regards,
Antoine Sauray


New Idea proposal vetting

Chris Berry <bez625@...>
 

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 - addressing issues #3481 and #2298.

We have raised a PR as a working proof of concept and have been trying to get some feedback from the maintainers: https://github.com/helm/helm/pull/10309

We have been asking on Kubernetes #helm-dev channel for feedback, but haven't got any response yet. We don't really want to put more work in to this, e.g. docs and testing, if the idea will be rejected outright. 

Thanks for your time
Chris 


New Idea proposal vetting - adding hook logs output

bez625@...
 

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 - addressing issues #3481 and #2298.
 
We have raised a PR as a working proof of concept and have been trying to get some feedback from the maintainers: https://github.com/helm/helm/pull/10309
 
We have been asking on Kubernetes #helm-dev channel for feedback, but haven't got any response yet. We don't really want to put more work in to this, e.g. docs and testing, if the idea will be rejected outright. 
 
Thanks for your time
Chris 


Re: Triage Maintainer Self Nomination: Allen Bai

Matt Farina
 

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 Farina

On Sep 9, 2021, at 1:55 PM, Allen Bai <abai@redhat.com> wrote:

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






Re: Triage Maintainer Self Nomination: Joe Julian

Marc Khouzam
 

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 over.

Thanks again

Marc

On Thu, Oct 28, 2021 at 13:00 Joe Julian <me@...> wrote:
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
maintainer doing triage, and have been helping on issues, where I can,
without being official. I would love to have this opportunity to
contribute more.

GitHub: https://github.com/joejulian
Twitter: https://twitter.com/JoeCyberGuru







Re: Triage Maintainer Self Nomination: Joe Julian

Josh Dolitsky
 

+1

On Thu, Oct 28, 2021 at 1:00 PM Joe Julian <me@...> wrote:
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
maintainer doing triage, and have been helping on issues, where I can,
without being official. I would love to have this opportunity to
contribute more.

GitHub: https://github.com/joejulian
Twitter: https://twitter.com/JoeCyberGuru







Triage Maintainer Self Nomination: Joe Julian

Joe Julian
 

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 maintainer doing triage, and have been helping on issues, where I can, without being official. I would love to have this opportunity to contribute more.

GitHub: https://github.com/joejulian
Twitter: https://twitter.com/JoeCyberGuru


Chart JSON schema

jmaury@...
 

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 source of information to get the structure of the values that needs to be provided ? Seems the values file is about default values so may not be complete or event present at all. So do you know where is the source of intormation ?


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 EngineerRHCE 
Red Hat



--

Michael Hrivnak

Senior Principal Software EngineerRHCE 

Red Hat

1 - 20 of 435