Re: Helm 3 "state"? Is there such a thing

Fox, Kevin M <Kevin.Fox@...>

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.


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


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<> and<> 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.


Join { to automatically receive all group messages.