Not sure where you got the information that the atomic flag doesn’t exist in Helm 3. I just checked, and it’s been there since Helm 3.0.0, and it’s present in

Hi, Does anyone have ideas about supporting automatic rollback in terms of failures? Over slack, people recommend different sets of tools. What is the recommended approach or best feasible approach to

Hi Teja! Both are completely valid option. People generally like the rollback commands as it's rolling your kubernetes manifests back to a known good version, therefore if there was an error

Hi, I was looking at downgrading software on failure. I wonder if I need to run upgrade an older version or use the "helm rollback" command. Well, I don't have enough arguments about why I need to use

Hi Berin The answer should also depend on what's your intention to group these pieces together. If the intention is to packaging and distributing, Paul's suggestion of two-layer charts should work.

Out of curiosity, why wouldn't you simply have a master helm chart for the full application that declares all of the dependencies? As opposed to learning yet another tool

The complication I have is that the customer I have has very outdated concepts for approving and managing deployments. As a result, our devops pipeline is segregated from the production environment.

In my opinion at least, Ideally each microservice would have its own fully independent chart, and be deployed and managed independely by some sort of CI/CD solution that roughly resembles gitops. If

Congratulations on the launch, Rimas!

Helm charts make your Kubernetes deployments as easy as possible and today I’m happy to announce: ChartCenter, the free central repository for Helm charts. chartcenter.io is an immutable, safe,

As I dive deeper into the world of Kubernetes so that I understand what I need my charts to do, and how I intend to design the templates for my environment, I am curious how Helm ties things

Hi, I would like to know can we use the same helm chart template for python and java sprinboot applications. I have my git repository name(sample) is common for these both the codes. But it uses

Hey, Helm Charts themselves can't access contents of a configmap. You could either set these values as `global` values and make them available across all charts (if using chart dependencies/child

Hi Marvin, I believe the dependency entry should as follows ( `..` instead of `.` since the game-tracker chart is in the same parent directory as `teamdb-ui`: ``` dependencies: - name: game-tracker

Hi, I've got two charts on my filesystem - which are not uploaded yet to any repo. They are both located in the same directory. [zaphod@oc3027208274 helm]$ ls game-tracker teamdb-ui Snippet from

I'm newbie to helm and trying to understand and develop helm charts for my organization, so pardon my knowledge on the subject.This is my idea of sharing a common library configmap to access across

Yeah. versioning is always quite complicated. Distro's have had a lot more time to figure it out. If you look at the way distro's typically version things, you see something

Its a lot to unpack, but in https://github.com/pnnl-miscscripts/miscscripts there are scripts to: 1. automatically build containers with newest versions of dependencies 2. apply a new version number

It does help. The main thing I'm looking for is to wrap my head around the thinking into how versioning was designed to work with helm. It's a big difference between saying "yeah that's a thing that

Berin, I am not entirely sure of your workflow so these are just ideas and thoughts in the area. First, appVersion is optional. You do not need to use it if you don't want to. Second, if you are using