replicatedhq
kots pull does not resolve namespaces
Kots Version: 1.16.1 / 1.17.0-scratch
When running kots pull ... -n <my-desired-namespace> the desired namespace is never resolved anywhere that makes use of '{{repl Namespace}}', any items that Helm uses for the {{ .Release.Namespace }}, or added to the kustomization.yaml. Applying directly according to the output of kots, i.e kubectl apply -k ... lead to all resources going to the default namespace.
Applying a namespace manually in the kustomization.yaml fixes the resources going to the correct location, but means that in my case, Config and some of the Helm templating is then incorrect for the deployed namespace.
@adamcoppard if the namespace was written to the generated kustomization.yaml, would that be expected?
@marccampbell - that would solve one problem - but not all.
I have cases where the bundle either has things like '{{repl Namespace}}' in ConfigMaps from the upstream vendor provided application, or, Helm charts that expect to be able to template out {{ .Release.Namespace }}. It appears that kots does this before applying it (i.e when going from upstream to the base and overlays). The -n flag is ignored for either of these replacements, too, when doing kubectl kots pull -n <namespace>. This means that, whilst the resources do go to the right namespace if you add a namespace: <namespace> to kustomization.yaml - but any thing else that expects to be able to resolve what namespace it's in (a good example are the args passed to NGINX Ingress Controller - which expects to preface the ConfigMap name with the namespace so it can be found) does not.
I believe one workaround for this today is to set the POD_NAMESPACE environment variable to your desired namespace before running kots pull - that's what's used by the template function internally.
https://github.com/replicatedhq/kots/blob/a76607458165ba17b7832414b1539aec51d810f7/pkg/template/static_context.go#L340
