|
Request for review/merge #10867
Jan-Otto Kröpke <mail@...>
Hello,
I would really appeciate it, if a helm maintainer could take a look at https://github.com/helm/helm/pull/10867. @joejulian did already a review as non core maintainer and redirect me to the mailing list here. The background of the pull request is described here: https://github.com/helm/helm/issues/10866 Thanks a lot, Jan
|
|
|
|
Request for review/merge PR #10867
Jan-Otto Kröpke
Hello,
I would really appeciate it, if a helm maintainer could take a look at https://github.com/helm/helm/pull/10867. @joejulian did already a review as non core maintainer and redirect me to the mailing list here. The background of the pull request is described here: https://github.com/helm/helm/issues/10866 Thanks a lot, Jan
|
|
|
|
Helm 3.9.0 release date changed
Matt Farina
Kubernetes has delayed the release of 1.24. Helm minor releases follow the minor releases of Kubernetes so that we can incorporate updates. Due to the delay in Kubernetes, which is currently scheduled for release on May 3rd, we are delaying the Helm 3.9 release candidate and full release by one week. Regards, Matt Farina
|
|
|
|
Need help for PR merging
Sunil
|
|
|
|
How to specify a "part-of" label on the Helm Release resource.
bharper@...
Openshift environment, and we have a group of deployments we'd like to have grouped in the console UI. We've specified a "part-of" (app.kubernetes.io/part-of) label for all the apps, but have to manually add this label to the Helm Release to have them all group accordingly in the UI. Any way to add that label to the Helm Release?
|
|
|
|
Re: Found some issue with helm 3.7.2 .
Wasim Khan <wasimcloud91@...>
Oh, Thanks Martin, I didn't figure that minute difference. Thanks for bringing it to my attention. Thanks & Regards, Wasim Khan
On Fri, 11 Feb 2022 at 02:46, Martin Hickey <martin.hickey@...> wrote:
|
|
|
|
HIP: Introduce a `export-values` feature for mapping values from parent chart to child charts
von Loewenstein, Jan <jan.von.loewenstein@...>
Hi Helm maintainers and Helm users,
we've created a HIP PR (helm/community#/242) for introducing a feature that was originally proposed with helm/helm#3242.
There have been multiple attempts to implement this.
However, most if not all of which ended up with a request to explain and document before implementing and in general to follow the Helm Improvement Proposal process, which has never happened.
Thinking that the idea had been discussed multiple times and had not really been questioned substantially, we've skipped the "Start
with an idea" phase and went on to directly provide a HIP via PR.
I hope this will not diminish the chance of getting a discussion rolling, get feedback from the community and getting a review from the Helm maintainers.
What is the next step? I'd be happy to discuss our HIP via PR review or in person (well, virtually) if the need arises. Feedback about how we can improve the proposal is most welcome.
Thanks, and bet regards
Jan (but I am merely the messenger)
|
|
|
|
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.
But we feel 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: [ "Ralf Van Dorsselaer" ]
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.1 where the number after the last dot is the "number of chunk".
If no splitting is required then no metadata and no dot"number of chunk" suffix are 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.
## 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
TODO add link to our PR.
## Rejected ideas
TODO Why certain ideas that were brought while discussing this HIP were not
ultimately pursued.
## Open issues
TODO Any points that are still being decided/discussed.
## References
TODO A collection of URLs or materials used as references through the HIP.
Thanks, Ralf
|
|
|
|
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!!
|
|
|