New idea proposal vetting - split large Helm encoded release data across multiple K8s secrets
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
|
|
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 ----- |
|
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 history edfi-connecter -n edfi and the got release-name got installed with helm upgrade --install release-name -n namespace Output of Output of Cloud Provider/Platform (AKS, GKE, Minikube etc.): Thanks & Regards, Wasim Khan On Thu, 10 Feb 2022 at 13:26, Wasim Khan <wasimcloud91@...> wrote:
|
|
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
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:
|
|
Re: 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:
|
|
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
I guess I was too eager 😇 I should wait for the official vote to open
|
|
Re: Nomination for Helm Org maintainer: Karen Chu
+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
I accept the nomination!!
|
|
Nomination for Helm Org maintainer: Karen Chu
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
toggle quoted message
Show quoted text
Le mar. 30 nov. 2021 à 16:27, Antoine Sauray <antoine.sauray@...> a écrit : Hi 👋 |
|
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.
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,
toggle quoted message
Show quoted text
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: |
|