Date   

Core Maintainer Self Nomination: yxxhero

苑雄雄
 

I would like to nominate myself as a core maintainer.

I'm a SRE engineer and have been using helm in production for many years. I have become a triage maintainer and am familiar with helm code, so I want to become a core maintainer and make more contributions to helm, including solving issue and pull request. look forward to your comments.

GitHub: https://github.com/yxxhero


Re: Question about Helm summit

Matt Butcher
 

I believe Karen is on this list. She is also frequently in the Kubernetes slack.

Twitter: @FermyonTech


From: Yair Etziony <yair.etziony@...>
Sent: Wednesday, June 1, 2022 3:21:27 PM
To: Matt Butcher <matt.butcher@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] Question about Helm summit
 
Hi Matt
Thank you for the response, 
Any idea how to communicate with Karen ? Is she on this list ?

Kind regards 

Yair 

On Tue 31. May 2022 at 19:01, Matt Butcher <matt.butcher@...> wrote:
We had discussed collocating with KubeCon prior to COVID. I am not sure if that is the plan for Helm Summit in the future. Karen (the community manager for Helm) might know better.

Matt

From: cncf-helm@... <cncf-helm@...> on behalf of Yair Etziony via lists.cncf.io <yair.etziony=polarsquad.com@...>
Sent: Monday, May 30, 2022 5:12:49 AM
To: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] Question about Helm summit
 
Hello,

My name is Yair Etziony; i am the head of operations for Polar Squad Germany. 

We are A DevOps consultancy with offices in Finland, Germany, and Spain. We are advocates of open source software and part of the CNCF.

In 2019 I was part of the Helm Summit EU, I helped create the program, and i enjoyed the event. As a person managing a company doing DevOps and is part of the CNCF, i am wondering if there is another planned event in the EU in the future? If so, i would gladly like to help and support it (from the curation side of things and maybe in other ways).
I believe that Helm and the community behind it are essential for the cloud-native and DevOps movements, and helping with an event like this is a crucial task for me.

Kind regards

Yair

--
Yair Etziony
Head Of Operations Germany

--
Yair Etziony
Head Of Operations Germany


Re: Question about Helm summit

Yair Etziony <yair.etziony@...>
 

Hi Matt
Thank you for the response, 
Any idea how to communicate with Karen ? Is she on this list ?

Kind regards 

Yair 

On Tue 31. May 2022 at 19:01, Matt Butcher <matt.butcher@...> wrote:
We had discussed collocating with KubeCon prior to COVID. I am not sure if that is the plan for Helm Summit in the future. Karen (the community manager for Helm) might know better.

Matt

From: cncf-helm@... <cncf-helm@...> on behalf of Yair Etziony via lists.cncf.io <yair.etziony=polarsquad.com@...>
Sent: Monday, May 30, 2022 5:12:49 AM
To: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] Question about Helm summit
 
Hello,

My name is Yair Etziony; i am the head of operations for Polar Squad Germany. 

We are A DevOps consultancy with offices in Finland, Germany, and Spain. We are advocates of open source software and part of the CNCF.

In 2019 I was part of the Helm Summit EU, I helped create the program, and i enjoyed the event. As a person managing a company doing DevOps and is part of the CNCF, i am wondering if there is another planned event in the EU in the future? If so, i would gladly like to help and support it (from the curation side of things and maybe in other ways).
I believe that Helm and the community behind it are essential for the cloud-native and DevOps movements, and helping with an event like this is a crucial task for me.

Kind regards

Yair

--
Yair Etziony
Head Of Operations Germany

--
Yair Etziony
Head Of Operations Germany


Re: Question about Helm summit

Matt Butcher
 

We had discussed collocating with KubeCon prior to COVID. I am not sure if that is the plan for Helm Summit in the future. Karen (the community manager for Helm) might know better.

Matt


From: cncf-helm@... <cncf-helm@...> on behalf of Yair Etziony via lists.cncf.io <yair.etziony=polarsquad.com@...>
Sent: Monday, May 30, 2022 5:12:49 AM
To: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] Question about Helm summit
 
Hello,

My name is Yair Etziony; i am the head of operations for Polar Squad Germany. 

We are A DevOps consultancy with offices in Finland, Germany, and Spain. We are advocates of open source software and part of the CNCF.

In 2019 I was part of the Helm Summit EU, I helped create the program, and i enjoyed the event. As a person managing a company doing DevOps and is part of the CNCF, i am wondering if there is another planned event in the EU in the future? If so, i would gladly like to help and support it (from the curation side of things and maybe in other ways).
I believe that Helm and the community behind it are essential for the cloud-native and DevOps movements, and helping with an event like this is a crucial task for me.

Kind regards

Yair

--
Yair Etziony
Head Of Operations Germany


Question about Helm summit

Yair Etziony <yair.etziony@...>
 

Hello,

My name is Yair Etziony; i am the head of operations for Polar Squad Germany. 

We are A DevOps consultancy with offices in Finland, Germany, and Spain. We are advocates of open source software and part of the CNCF.

In 2019 I was part of the Helm Summit EU, I helped create the program, and i enjoyed the event. As a person managing a company doing DevOps and is part of the CNCF, i am wondering if there is another planned event in the EU in the future? If so, i would gladly like to help and support it (from the curation side of things and maybe in other ways).
I believe that Helm and the community behind it are essential for the cloud-native and DevOps movements, and helping with an event like this is a crucial task for me.

Kind regards

Yair

--
Yair Etziony
Head Of Operations Germany


Request to join https://github.com/helm/helm-www

苑雄雄
 

Hello everyone, I apply to join https://github.com/helm/helm-www , in order to contribute to the document, especially Chinese, I hope to get your support. My GitHub: https://github.com/yxxhero.  Thanks very much.


helm install isn't working behind proxy

Majed Dobyani <mbth201@...>
 

Hello
I use Ubuntu20.04, kubernetes 24 and helm 3. I already set up all proxy configurations for environment, apt , bashrc and wgerc and everything works fine. I can pull images from kubernetes and update the OS via proxy. But helm install is not working behind proxy and I got failed download. without proxy it is working fine.
I appreciate any help or clue to fix this issue and be able to install charts using proxy. 


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
 

Hi Team,

  Please anyone help me for merge this PR, I need it very badly.

 

Thanks
Sunil Kumar


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:
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

 



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

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

1 - 20 of 454