4 ms·

I'd prefer to deploy full manifests as well, but it's not my impression that you can entirely obtain those though "helm template". Certain variables, like "Rele

by broeng 4y ago

I'd prefer to deploy full manifests as well, but it's not my impression that you can entirely obtain those though "helm template". Certain variables, like "Release.namespace" are only available when actually being applied, AFAIK. You will get a manifest, but it will usually be missing certain parts of it. I completely agree with the philosophy of just redeploying the cluster if it's borked. I'm using NixOS myself for the task, and was trying to obtain full manifests though "helm template" originally -- so I'd love to know, if I was just missing something.

AaronM 4y ago
This isn't a problem we have seen before, and we deploy allmost all of the third party applications in this manner. When we generate the templates we use -n to override the namespace. The command looks like this helm template CHART_NAME CHART_PATH -f CHART_INPUT_PATH/config.yaml --output-dir CHART_OUTPUT_PATH/manifests -n NAMESPACE --include-crds --render-subchart-notes --kube-version KUBE_VERSION
- broeng 4y ago
  My memory didn't quite serve me right, so it's not exactly as I described, and I can see, that as you say, providing the namespace to the template command does work. The problem for me is, that setting the namespace in that way with "helm template" does not seem to add it to any manifests not specifically specifying the namespace to .Release.Namespace. The rancher 2.6.8 chart does not set this for all manifests, but does with some, so when I set namespace though template, and deployed it all through the manifests folder, I got some objects in default namespace (because they had none specified), and some in the intended namespace; resulting in an installation that did not work. As another reply to my comment suggested, this can of course be handled with post-processing of the result of "helm template", though, at the time, I was not certain the problem was limited to this namespace issue, so I didn't feel lucky enough to go down that route. :-)
barefeg 4y ago
About the namespace, I usually modify it manually if it’s a few files, otherwise use some post processing like https://github.com/helm/helm/issues/3553#issuecomment-417800691 https://github.com/helm/helm/issues/3553#issuecomment-417800...
- broeng 4y ago
  That could definitely work. And I considered it a bit but didn't feel confident that the problem would be limited to the namespace, so it felt like the wrong tool for the job at the time. :-) Thank you for the suggestion though. It's comforting to hear that it may actually be a viable approach.

by broeng 4y ago

AaronM 4y ago

This isn't a problem we have seen before, and we deploy allmost all of the third party applications in this manner. When we generate the templates we use -n to override the namespace. The command looks like this helm template CHART_NAME CHART_PATH -f CHART_INPUT_PATH/config.yaml --output-dir CHART_OUTPUT_PATH/manifests -n NAMESPACE --include-crds --render-subchart-notes --kube-version KUBE_VERSION

broeng 4y ago
My memory didn't quite serve me right, so it's not exactly as I described, and I can see, that as you say, providing the namespace to the template command does work. The problem for me is, that setting the namespace in that way with "helm template" does not seem to add it to any manifests not specifically specifying the namespace to .Release.Namespace. The rancher 2.6.8 chart does not set this for all manifests, but does with some, so when I set namespace though template, and deployed it all through the manifests folder, I got some objects in default namespace (because they had none specified), and some in the intended namespace; resulting in an installation that did not work. As another reply to my comment suggested, this can of course be handled with post-processing of the result of "helm template", though, at the time, I was not certain the problem was limited to this namespace issue, so I didn't feel lucky enough to go down that route. :-)

barefeg 4y ago

About the namespace, I usually modify it manually if it’s a few files, otherwise use some post processing like https://github.com/helm/helm/issues/3553#issuecomment-417800691 https://github.com/helm/helm/issues/3553#issuecomment-417800...

broeng 4y ago
That could definitely work. And I considered it a bit but didn't feel confident that the problem would be limited to the namespace, so it felt like the wrong tool for the job at the time. :-) Thank you for the suggestion though. It's comforting to hear that it may actually be a viable approach.