Hello, I would like to understand if there is already someone working on the development of an exclusion/ignore list option for helm lint, that can be used to skip errors (or mark them as a warning) when a specific file is added to it. If not, would it be something that the community is interested into? Regards Danilo

Hi All, It's been a pleasure being a core maintainer on the Helm project and a Helm org maintainer. I am officially stepping down as a core maintainer and an org maintainer to focus on other responsibilities. Thank you for all the memories and the fun working with you all. Cheers, Martin

Hey folks, I would like to nominate Evans Mungai as a Triage Maintainer. For the past 8 months, Evans has shown commitment by being active in the Helm developer meetings and also helping triage issues and review PRs. As a triage maintainer, he would be enabled to be more involved in the project support the core maintainers in approve PRs, categorise incoming issues etc, helping ease the work of core maintainers. For anyone curious, see hip-0014.md for details. -- Scott Rigby Pronouns: he/they ~ See pronouns.org to learn more

Hi Following up on the discussions in https://github.com/helm/helm/issues/11863 it was outlined that the next step would be to write a HIP and since https://github.com/helm/community/blob/main/hips/hip-0001.md demands to first ask for an OK in this mailing list, I am attempting to achieve that. The idea is to simplify the handling for both manual users as well as CI/CD pipelines, to auto-recover from a state of stuck deployments, which is currently not possible unless users implement boiler-plate code around their helm invocations. The discussions already mention some key ideas how this could be solved which I summarize here: Each upgrade/install operation that uses the –timeout parameter also transmits two new “fields” for a helm release (the helm release state that is already stored as a k8s secret in the cluster since helm3 and the information of which can be displayed with ‘helm ls -a’ – we can hide time if the -a flag is omitted.): LOCKED TILL <datetime> calculated by the helm client:k8s server time + timeout parameter value SESSION ID Unique, random session id generated by the client So all new clients will only start or continue upgrading if old clients timed out based on the ‘helm ls -a’ information, or no old operations are pending. I would also implement the logic that if the helm client process gets killed (SIGTERM), it tries to clear the LOCKED TILL value, SESSION ID and sets the release into a failed state before terminating. This way, a retry can happen immediately in the normal case. The idea is of course to implement this in a backward-compatible way, which needs to be tested of course. I am curious of whether you give your OK for the HIP or have any other remarks! Regards, Gernot BearingPoint GmbH Sitz: Wien Firmenbuchgericht: Handelsgericht Wien Firmenbuchnummer: FN 175524z The information in this email is confidential and may be legally privileged. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.

Helm v3.14.4 is now released. Look forward to the next feature release Helm 3.15.0, which is scheduled to be released on May 08.

Helm v3.14.2 is out with a CVE fix is out. You can get it at https://github.com/helm/helm/releases/tag/v3.14.2

Hi folks, I happy to nominate George Jenkins for core Helm Maintainer. For new folks, Helm maintainer nominations happen on this public Helm mailing list (while voting happens on the private maintainers mailing list. See this section in Helm governance for more info on the process). George has been a triage maintainer for the past 8 months, during which time he has consistently helped with issue triage, pull request review, and other triage maintainer duties (for anyone interested in how this works, or becoming a Triage Maintainer, see hip-0014.md and please reach out to us). His contributions have far exceeded Triage Maintainer scope for quite a while now: moderating Helm dev meetings, writing PRs to fix user bugs and feature requests, collaborating with core maintainers on both Helm 3 improvements and the Roadmap for Helm 4. The Helm team values George's contributions – and I think, whether or not they know it yet, the wider Helm community does too. xo, Scott

Helm v3.14.1 is out with a CVE fix is out. You can get it at https://github.com/helm/helm/releases/tag/v3.14.1

hello

The first release candidate for Helm v3.13.0 is now available. This release candidate contains numerous changes and this is your opportunity to test it. This includes multiple bug fixes around values handling with regard to imported values from sub-charts, using null to remove default values, etc. If you find any issues with the release candidate, please file an issue with the Helm project.

Values handling has had some long standing bugs. A recent change designed to fix them has landed and is slated for Helm v3.13.0. These changes are worth the community looking at ahead of their release to provide any feedback. You can try them out now by using a canary build. Warning, this is the tip of the main branch rather than a release. These changes include: nil/null can now consistently delete subkeys. Previously, this worked sometimes and failed to work other times. It depended on the code path and was inconsistent. Closed #9027 Imported values are now used in the following order (which was the original intent but did not work consistently - it only sometimes worked this was and was often broken) - Closed #10899: User specified values (e.g CLI) Imported Values Parent Chart Values Subchart Values Imported values using the parent/child designation often didn't work. There were some ways to make it work but it often didn't. Closed #10052 These changes were all to fix bugs where things sometimes worked if you knew the tricks but didn't work other times. The full change (which is mostly testing) can be found at https://github.com/helm/helm/pull/12162 If you find issues with these changes please let us know. Regards, Matt Farina

I've been involved with the developer calls for a few months now, and wanting to get more involved with helping. I'd like to become more of a part of helping helm user's ideas get implemented and seeing a vision for what the future of helm could be. Thanks, Ian

Hello, i'm working with an employer that is looking to hire a Linux platform engineer for their office in India and Singapore that has experience in automation and management of platform configuration from both an onprem and cloud perspective. Consequently, I had hoped that some members may like to discuss further; off-list. I can be reached using "JamesBTobin (at) Gmail (dot) Com". Kind regards, James

Hi all, Before starting a Hip, I'd like to throw around the idea I had for improving Helm. Issue: Currently, when dependencies are added with conditions e.g. dependencies: - name: nginx version: "1.3.1" condition: is.stg The conditional is respected only during the actual installation process. When running helm dependency update All dependencies regardless of the conditionals are imported. This is slightly confusing as I've seen multiple issues opened around this (why the conditionals are not working). This also makes using different versions of dependencies in different environments not so easy for example Helm library Charts would need something like this dependencies: - name: nginx version: "1.3.1" condition: is.stg alias: nginx-staging - name: nginx version: "1.2.1" condition: is.prd alias: nginx-production And in the chart itself {{- if ( .Values.is.stg ) }} {{- include "helm-library-staging.hpa" . }} {{- else if ( .Values.is.prd )}} {{- include "helm-library-production.hpa" . }} {{- end }} This seems more like a workaround than how it should work. Proposal: Have Helm dependency update look at the conditionals. This would just require to reuse the current code used during installation and than we can work with this straightforward without workarounds. Looking forward to your feedback Yonah

Hi, I work with a project (https://troubleshoot.sh/) that includes a binary which executes tests on a cluster (or a host) prior to installation of an app. These tests generally include items which prove the environment meets the app's requirements for installation and operation, and happen prior to installation so that folks don't have to spend time diagnosing failed installs - the output just tells them what's missing and they can go fix it before trying again. As our folks use Helm more and more, we're wondering if there's a variation on 'helm test' that might run before installation, rather than afterwards? And if not, is there appetite for a contributor to come along and add a command (e.g. `helm preflight`) to run a different set of tests prior to install? Of course we could use a plugin for that, however this feels like something which would be more about an execution order than a whole new set of software. I'm happy to write up the HIP if there's appetite for a feature like that. Thanks Xav -- Xav Paice (they/them) Engineering Manager

Hello, I am using EKS, I configured the installation for Prometheus, but when trying to overwrite settings does not, I had to modify the configmap manually, mayby something wrong in my yaml file? serviceAccounts: server: name: "service-account" annotations: eks.amazonaws.com/role-arn: arn:aws:iam::xxxxxxxxxxxxxx:role/ServiceAccount-Role server: remoteWrite: - url: https://aps-workspaces.xx-xxxx-x.amazonaws.com/workspaces/xxxxxxxxxxxx/api/v1/remote_write queue_config: max_samples_per_send: 1000 max_shards: 200 capacity: 2500 sigv4: region: xx-xxxx-x role_arn: arn:aws:iam::xxxxxxxxxxxxx:role/Role statefulSet: enabled: "true" scrape: enabled: true scrape_configs: - job_name: statsd_metrics metrics_path: /metrics static_configs: - targets: ['xxxxxxxxxxxxxxx:9102']

Hello, I'm running the following commands in a CI/CD environment: helm dependency update $DEPLOY_NAME helm upgrade $DEPLOY_NAME $DEPLOY_NAME -i -f values.yaml ${ADDITIONAL_VALUES_YAML_ARG} -n $VAL_NAMESPACE I have a chart.yaml like the following: apiVersion: v2 name: myName description: Sample chart type: application version: "2.0" appVersion: "2.0" dependencies: - name: rabbitmq alias: rabbitmq version: 11.1.1 repository: https://marketplace.azurecr.io/helm/v1/repo Each time I run the helm upgrade command from above, pods and containers are recreated in the Kubernetes cluster although the chart.yaml has not changed. Is there a mean to prevent such behavior and only update the delta? Thanks David.

Hi all, I'd like to open a HIP for a feature request described in this issue: https://github.com/helm/helm/issues/8991 The goal is to allow third-party tooling, like Nova and Pluto, to view metadata about Helm state (release name, version, chart source, etc) without needing RBAC that grants them access to Secrets. Currently, for Nova and Pluto to do their job, they need Secrets access, which is a huge security concern, and prevents some organizations from adopting them. If a HIP would be appropriate, I'm happy to flesh out this idea some more and open a PR. -Robert -- Robert Brennan | VP of Product Development robertb@... Automate, monitor, and enforce Kubernetes best practices Fairwinds Insights | Schedule a Demo

Hi all, just wanted to ask if it’s possible to deploy a persistent Ceph rbd volume for a container with a helm chart. The Ceph cluster does not run with rook, its managed outside. If yes, do you know any example helm chats for this? Regards Marcus