Date   

New idea proposal vetting - split large Helm encoded release data across multiple K8s secrets

ralfv
 
Edited

Hello,

Idea

Some of our charts create during install/upgrade secrets that are bigger than 1MB. Then Helm install/upgrades fail.

We can take some measures to remove content and cleanup charts but we can only do so much.

Our idea is to have Helm create multiple secrets to hold a Helm release.

The encoded release data would be split across multiple secrets created as needed if the encoded release data is > 1MB.

We have a working implementation of this implemented as an additional storage driver called "chunkedsecrets" which can be enabled by setting the HELM_DRIVER=chunkedsecrets environment variable.

Eventually it is better to integrate chunking into the standard secret/secrets storage driver and add automatic chunking only if the size of the encoded release data becomes too big.

Proposal

hip: 9999
title: "Support Helm release data stored in multiple K8s Secrets"
authors: [ "" ]
created: "2022-02-10"
type: "feature"
status: "draft"

Abstract

Helm release data encoded into the release field in a Kubernetes Secret can cause the Secret as a whole to exceed 1 MiB (as defined by MaxSecretSize in kubernetes/pkg/apis/core/types.go).

When this happens, the Kubernetes Secret cannot be stored in Etcd and the Helm install or upgrade fails.

Splitting the Helm release data across multiple Kubernetes Secrets resolves this problem.

Motivation

Helm release data that causes the Kubernetes Secret size to exceed MaxSecretSize will make Helm install or upgrade fail.

The existing HELM_DRIVER=secret storage driver does not handle Kubernetes Secrets become too big when storing a large encoded Helm release data.

Rationale

The logical place to support this is in the HELM_DRIVER=secret storage driver.

Specification

The feature is transparent to users.

When the HELM_DRIVER=secret storage driver notices that the resulting Kubernetes Secret will exceed MaxSecretSize then the storage driver will split the encoded release data across multiple Kubernetes Secrets.

Splitting requires additional metadata to be added to the Kubernetes Secret:

  • number of chunks: integer, the number of Kubernetes Secrets that holds the release data for this Helm release version.
  • chunk: integer, the chunk number. Each Secret gets a chunk number. Reconstituting the release data can be done by reading the Secret with chunk=1, then subsequently reading in numerical order any number of additional Secrets up to and including the "number of chunks".

Splitting requires the name of the Secret to include a "chunk" suffix. Example: sh.helm.release.v1.test.v1.2, 3, 4 and so on where the number after the last dot is the "number of chunk". The first Secret will not get a .1 suffix.

If no splitting is required then no additional metadata is included/set.

Backwards compatibility

If the chunking is implemented in the secret/secrets HELM_DRIVER then backward compatibility to previously installed Helm releases is guaranteed. If no chunking information is encoded in the release secret then the driver can behave as before chunking support was added. If no chunking is needed then the release secret can be created without any additional metadata and with compatible name.

Security implications

Theoretically a MTM Man in The Middle attack is possible where requests to the Kubernetes API server are intercepted. But this type of attack applies to any access to the Kubernetes API server.

How to teach this

The feature is transparent to users.

The documentation (in advanced section(s)) needs to explain that multiple Kubernetes Secrets can be created for a Helm release to counter the size limitation.

Reference implementation

We can submit a PR for this.

Rejected ideas

n/a

Open issues

https://github.com/helm/helm/issues/10986

References

n/a


Re: Found some issue with helm 3.7.2 .

Martin Hickey
 

Hi Wasim,
 
From the 'helm list' command. below, one is named 'edfi-connecter' and the other is named 'edfi-connector'. They are different because one ends in 'er' and the other in 'or'.

Regards,
Martin

 

----- Original message -----
From: "Wasim Khan" <wasimcloud91@...>
Sent by: cncf-helm@...
To: cncf-helm@...
Cc:
Subject: [EXTERNAL] Re: [cncf-helm] Found some issue with helm 3.7.2 .
Date: Thu, Feb 10, 2022 7:39 PM
 
Hello Team, Found that two releases names having the same names can run within the same namespace. Can some developer folks look into this? Output for reference: helm list -n edfi NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION ‍ ‍ ‍ ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hello Team,
 
Found that two releases names having the same names can run within the same namespace.
 
Can some developer folks look into this?

 

Output for reference:
helm list -n edfi
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
edfi-connecter edfi 2 2022-01-21 18:09:33.2841518 +0530 IST deployed edfi-0.1.0 1.16.0
edfi-connector edfi 1 2022-02-03 16:33:25.521377174 +0530 IST deployed edfi-connector-0.1.0 1.16.0

helm history edfi-connecter -n edfi
REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
1 Fri Jan 21 18:04:08 2022 superseded edfi-0.1.0 1.16.0 Install complete
2 Fri Jan 21 18:09:33 2022 deployed edfi-0.1.0 1.16.0 Upgrade complete

and the got release-name got installed with helm upgrade --install release-name -n namespace

Output of helm version:v3.7.2
developer@CGLX-LPT-user11:~$ helm version
version.BuildInfo{Version:"v3.7.2", GitCommit:"663a896f4a815053445eec4153677ddc24a0a361", GitTreeState:"clean", GoVersion:"go1.16.10"}

Output of kubectl version:
developer@CGLX-LPT-user11:~$ kubectl version
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.2", GitCommit:"8b5a19147530eaac9476b0ab82980b4088bbc1b2", GitTreeState:"clean", BuildDate:"2021-09-15T21:38:50Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"21+", GitVersion:"v1.21.5-eks-bc4871b", GitCommit:"5236faf39f1b7a7dabea8df12726f25608131aa9", GitTreeState:"clean", BuildDate:"2021-10-29T23:32:16Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):
AWS EKS

 

 

 

Thanks & Regards,

Wasim Khan

 
On Thu, 10 Feb 2022 at 13:26, Wasim Khan <wasimcloud91@...> wrote:
Thank you Team for your response. 

Thanks & Regards,
Wasim Khan
 
On Thu, 10 Feb 2022 at 01:58, conduct <conduct@...> wrote:
Hi Wasim, 
 
This is the Kubernetes Code of Conduct Committee and it looks like the issues you raised our outside of our scope. We recommend reaching out directly to the Helm team via cncf-helm@...
 
Best regards,
Kubernetes CoCC

 
On Thursday, February 3, 2022 at 6:52:28 AM UTC-8 Wasim Khan wrote:
Hello Team,
 
Today found that two releases names are running with the same name within same namespace.
 
Can some developer folks look into this?

 

Output for reference:
helm list -n edfi
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
edfi-connecter edfi 2 2022-01-21 18:09:33.2841518 +0530 IST deployed edfi-0.1.0 1.16.0
edfi-connector edfi 1 2022-02-03 16:33:25.521377174 +0530 IST deployed edfi-connector-0.1.0 1.16.0

helm history edfi-connecter -n edfi
REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
1 Fri Jan 21 18:04:08 2022 superseded edfi-0.1.0 1.16.0 Install complete
2 Fri Jan 21 18:09:33 2022 deployed edfi-0.1.0 1.16.0 Upgrade complete

and the got release-name got installed with helm upgrade --install release-name -n namespace

Output of helm version:v3.7.2
developer@CGLX-LPT-user11:~$ helm version
version.BuildInfo{Version:"v3.7.2", GitCommit:"663a896f4a815053445eec4153677ddc24a0a361", GitTreeState:"clean", GoVersion:"go1.16.10"}

Output of kubectl version:
developer@CGLX-LPT-user11:~$ kubectl version
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.2", GitCommit:"8b5a19147530eaac9476b0ab82980b4088bbc1b2", GitTreeState:"clean", BuildDate:"2021-09-15T21:38:50Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"21+", GitVersion:"v1.21.5-eks-bc4871b", GitCommit:"5236faf39f1b7a7dabea8df12726f25608131aa9", GitTreeState:"clean", BuildDate:"2021-10-29T23:32:16Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):
AWS EKS

 

 

 

Thanks & Regards,

Wasim Khan

 



Re: Found some issue with helm 3.7.2 .

Wasim Khan <wasimcloud91@...>
 

Hello Team,

Found that two releases names having the same names can run within the same namespace.

Can some developer folks look into this?


Output for reference:
helm list -n edfi
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
edfi-connecter edfi 2 2022-01-21 18:09:33.2841518 +0530 IST deployed edfi-0.1.0 1.16.0
edfi-connector edfi 1 2022-02-03 16:33:25.521377174 +0530 IST deployed edfi-connector-0.1.0 1.16.0

helm history edfi-connecter -n edfi
REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
1 Fri Jan 21 18:04:08 2022 superseded edfi-0.1.0 1.16.0 Install complete
2 Fri Jan 21 18:09:33 2022 deployed edfi-0.1.0 1.16.0 Upgrade complete

and the got release-name got installed with helm upgrade --install release-name -n namespace

Output of helm version:v3.7.2
developer@CGLX-LPT-user11:~$ helm version
version.BuildInfo{Version:"v3.7.2", GitCommit:"663a896f4a815053445eec4153677ddc24a0a361", GitTreeState:"clean", GoVersion:"go1.16.10"}

Output of kubectl version:
developer@CGLX-LPT-user11:~$ kubectl version
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.2", GitCommit:"8b5a19147530eaac9476b0ab82980b4088bbc1b2", GitTreeState:"clean", BuildDate:"2021-09-15T21:38:50Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"21+", GitVersion:"v1.21.5-eks-bc4871b", GitCommit:"5236faf39f1b7a7dabea8df12726f25608131aa9", GitTreeState:"clean", BuildDate:"2021-10-29T23:32:16Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):
AWS EKS




Thanks & Regards,

Wasim Khan


On Thu, 10 Feb 2022 at 13:26, Wasim Khan <wasimcloud91@...> wrote:
Thank you Team for your response. 

Thanks & Regards,
Wasim Khan

On Thu, 10 Feb 2022 at 01:58, conduct <conduct@...> wrote:
Hi Wasim, 

This is the Kubernetes Code of Conduct Committee and it looks like the issues you raised our outside of our scope. We recommend reaching out directly to the Helm team via cncf-helm@...

Best regards,
Kubernetes CoCC


On Thursday, February 3, 2022 at 6:52:28 AM UTC-8 Wasim Khan wrote:
Hello Team,

Today found that two releases names are running with the same name within same namespace.

Can some developer folks look into this?


Output for reference:
helm list -n edfi
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
edfi-connecter edfi 2 2022-01-21 18:09:33.2841518 +0530 IST deployed edfi-0.1.0 1.16.0
edfi-connector edfi 1 2022-02-03 16:33:25.521377174 +0530 IST deployed edfi-connector-0.1.0 1.16.0

helm history edfi-connecter -n edfi
REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
1 Fri Jan 21 18:04:08 2022 superseded edfi-0.1.0 1.16.0 Install complete
2 Fri Jan 21 18:09:33 2022 deployed edfi-0.1.0 1.16.0 Upgrade complete

and the got release-name got installed with helm upgrade --install release-name -n namespace

Output of helm version:v3.7.2
developer@CGLX-LPT-user11:~$ helm version
version.BuildInfo{Version:"v3.7.2", GitCommit:"663a896f4a815053445eec4153677ddc24a0a361", GitTreeState:"clean", GoVersion:"go1.16.10"}

Output of kubectl version:
developer@CGLX-LPT-user11:~$ kubectl version
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.2", GitCommit:"8b5a19147530eaac9476b0ab82980b4088bbc1b2", GitTreeState:"clean", BuildDate:"2021-09-15T21:38:50Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"21+", GitVersion:"v1.21.5-eks-bc4871b", GitCommit:"5236faf39f1b7a7dabea8df12726f25608131aa9", GitTreeState:"clean", BuildDate:"2021-10-29T23:32:16Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):
AWS EKS




Thanks & Regards,

Wasim Khan


Recursive dependency HIP

Omer Kahani
 

Hi,
I'm following the HIP process for recursive dependency build (https://github.com/helm/helm/issues/2247, https://github.com/helm/helm/issues/1969, https://github.com/helm/helm/issues/4263)

The current implementation of the command only refers to the first level of dependencies. Meaning that if a chart requires a chart, and that chart requires a chart - running `helm dependency build` would not create a chart that is ready to use. The second level of dependencies would never get built.

The PR's were open in 2017, today they have 117 votes (emojis), 45 comments from 28 participants. 2 PRs were open for implementation https://github.com/helm/helm/pull/2278, https://github.com/helm/helm/pull/4468 but was closed for different reasons.

There is community demand for this feature, so I'm hoping a HIP would help drive it forward

As this is my first HIP, I would appreciate any help starting with open questions and concerns with adding a recursive flag to the build command.

The recursive flag would manage n-level of dependencies, so running `helm dependency build --recursive` would create a working helm chart.

Thanks,
Omer Kahani


Re: Nomination for Helm Org maintainer: Karen Chu

Paul C
 

I agree +1


On Sat, Jan 8, 2022 at 1:37 PM Ronan Flynn-Curran <dev@...> wrote:
I agree, +1 to add Karen


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