> My guess is that, during the 3-way merge, the mentioned "old manifest" is directly retrieved from the k8s master itself and that Helm doesn't store any release related information in the aforementioned directories.

Correct. State about the current release is stored server-side (in Kubernetes) as a Secret. The three-way merge patch pulls down this metadata, comparing it to the chart you are upgrading to (`helm upgrade release_name *CHART*`), and the live state.

Stuff stored in the XDG directories contain local setup information, such as

• repositories you've added (`helm repo list`)
• plugins you have installed
• cached repository indices
  
• cached charts pulled down from said repositories (either via `helm install` or `helm pull`)
  

It is entirely safe to run Helm from an ephemeral filesystem, such as a container. No state about what was installed in the cluster is stored locally.

More info: https://helm.sh/docs/topics/architecture/

Hope that answers your question.

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada

---

From: cncf-helm@... <cncf-helm@...> on behalf of Fox, Kevin M via Lists.Cncf.Io <Kevin.Fox=pnnl.gov@...>
Sent: Wednesday, February 5, 2020 12:05 PM
To: Abhirama <abhirama@...>; cncf-helm@... <cncf-helm@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] Helm 3 "state"? Is there such a thing

 

As far as I can tell, the "state" is made up of:
* caches
* credentials
* repos

So long as your stateless job (k8s pod) adds whatever credentials it needs and repo's as part of the job you should be fine loosing the state dirs when the pod is destroyed.

Thanks,
Kevin

________________________________________
From: cncf-helm@... <cncf-helm@...> on behalf of Abhirama <abhirama@...>
Sent: Tuesday, February 4, 2020 8:46 PM
To: cncf-helm@...
Subject: [cncf-helm] Helm 3 "state"? Is there such a thing

Hi,

I'm sorry if the question comes across as too lame.

Now that Helm 3 is client-only, I understand that it stores "state" information along with the client in the directories determined by the environment variables  XDG_CACHE_HOME, XDG_CONFIG_HOME and XDG_DATA_HOME. As a result, if Helm were to run on "stateless" machines (say if it were to run on a k8s pod every time it's run), does it still need access to the state it maintains in the aforementioned directories?

I've gone through https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelm.sh%2Fdocs%2Ffaq%2F%23improved-upgrade-strategy-3-way-strategic-merge-patches&amp;data=02%7C01%7Cmatt.fisher%40microsoft.com%7Ca90790d766fa472d4a4308d7aa76d525%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165299746162558&amp;sdata=iU6D6%2BlcJ52vp5P1NJbfmCSIKlqPNti%2B8ZLswWCFuxE%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelm.sh%2Fdocs%2Ffaq%2F%23improved-upgrade-strategy-3-way-strategic-merge-patches&amp;data=02%7C01%7Cmatt.fisher%40microsoft.com%7Ca90790d766fa472d4a4308d7aa76d525%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165299746162558&amp;sdata=iU6D6%2BlcJ52vp5P1NJbfmCSIKlqPNti%2B8ZLswWCFuxE%3D&amp;reserved=0> and https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelm.sh%2Fdocs%2Ffaq%2F%23xdg-base-directory-support&amp;data=02%7C01%7Cmatt.fisher%40microsoft.com%7Ca90790d766fa472d4a4308d7aa76d525%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165299746162558&amp;sdata=uXYvT8fSYoeGWHBP%2BGfzO%2BNC2zvrHBjPp0Y1Bgd91Ls%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelm.sh%2Fdocs%2Ffaq%2F%23xdg-base-directory-support&amp;data=02%7C01%7Cmatt.fisher%40microsoft.com%7Ca90790d766fa472d4a4308d7aa76d525%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165299746162558&amp;sdata=uXYvT8fSYoeGWHBP%2BGfzO%2BNC2zvrHBjPp0Y1Bgd91Ls%3D&amp;reserved=0> and wasn't able to completely iron out my confusion. My guess is that, during the 3-way merge, the mentioned "old manifest" is directly retrieved from the k8s master itself and that Helm doesn't store any release related information in the aforementioned directories.

I'd greatly appreciate your help in clarifying this.

Thanks,
Abhirama.