Re: Helm 3 "state"? Is there such a thing
|
Matt Fisher <matt.fisher@...>
> 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
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&data=02%7C01%7Cmatt.fisher%40microsoft.com%7Ca90790d766fa472d4a4308d7aa76d525%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165299746162558&sdata=iU6D6%2BlcJ52vp5P1NJbfmCSIKlqPNti%2B8ZLswWCFuxE%3D&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&data=02%7C01%7Cmatt.fisher%40microsoft.com%7Ca90790d766fa472d4a4308d7aa76d525%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165299746162558&sdata=iU6D6%2BlcJ52vp5P1NJbfmCSIKlqPNti%2B8ZLswWCFuxE%3D&reserved=0> and https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelm.sh%2Fdocs%2Ffaq%2F%23xdg-base-directory-support&data=02%7C01%7Cmatt.fisher%40microsoft.com%7Ca90790d766fa472d4a4308d7aa76d525%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165299746162558&sdata=uXYvT8fSYoeGWHBP%2BGfzO%2BNC2zvrHBjPp0Y1Bgd91Ls%3D&reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelm.sh%2Fdocs%2Ffaq%2F%23xdg-base-directory-support&data=02%7C01%7Cmatt.fisher%40microsoft.com%7Ca90790d766fa472d4a4308d7aa76d525%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165299746162558&sdata=uXYvT8fSYoeGWHBP%2BGfzO%2BNC2zvrHBjPp0Y1Bgd91Ls%3D&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. |
|
|
