search

replicatedhq / kots

KOTS provides the framework, tools and integrations that enable the delivery and management of 3rd-party Kubernetes applications, a.k.a. Kubernetes Off-The-Shelf (KOTS) Software.
https://kots.io
Apache License 2.0
898 stars 88 forks source link

kots pull does not resolve namespaces #747

Open adamcoppard opened 4 years ago

adamcoppard commented 4 years ago

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.

marccampbell commented 4 years ago

@adamcoppard if the namespace was written to the generated kustomization.yaml, would that be expected?

adamcoppard commented 4 years ago

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

laverya commented 4 years ago

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