Default namespace option (--k8s-default-namespace) has no effect

[michaelbeaumont]

Describe the bug

In spite of setting the --k8s-default-namespace option, the default namespace isn't applied to namespaced manifests without a specific namespace.

Seems to be present in the gitops-engine branch as well

To Reproduce

Steps to reproduce the behaviour:

1. Setup flux including the --k8s-default-namespace option. E.g.:

$ fluxctl install \
--git-user=test \
[email protected] \
--git-url=https://github.com/michaelbeaumont/flux_manifests \
--git-path=/ \
--git-readonly=true \
--namespace=flux > out.yaml
$ patch -p0 << EOF
> --- out.yaml    2020-01-29 14:21:09.447424403 +0100
+++ out_p.yaml   2020-01-29 14:21:45.957538447 +0100
@@ -190,6 +190,8 @@

         # Include this to enable git signature verification
         # - --git-verify-signatures
+
+        - --k8s-default-namespace=test

         # Tell flux it has readonly access to the repo (default `false`)
         - --git-readonly
> EOF

2. A simple pod manifest:
   https://github.com/michaelbeaumont/flux_manifests/tree/master

Expected behavior

The pod should be deployed in the test namespace, instead:

$ kubectl get pod -n default -o yaml
apiVersion: v1
kind: Pod
metadata:
  name: sleep
spec:
  containers:
  - name: sleep
    image: busybox
    command: ['sh', '-c', 'echo Started && sleep 3600']

Additional context

• Flux version: 1.17.1
• Kubernetes version: 1.16

[2opremio]

🤦‍♂️ after reviewing #2625 , I can see that the option is not honoured when invoking kubectl.

I will fix that.

[michaelbeaumont]

I was actually hoping to fix it myself!
@2opremio

[2opremio]

Even better, please do!

It should be as simple as passing --namespace to kubectl (assuming that gives higher precedence to the namespace explicitly provided by manifests)

[michaelbeaumont]

kubectl seems to throw an error if the namespaces disagree so that won't work. I guess the intended usage is to limit operations to a single NS, so it makes sense to throw an error.

[2opremio]

Then we will need to find another way. Maybe appending a default namespace as a configuration to `KUBECONFIG`?

…

On Wed, Jan 29, 2020, 17:11 Michael Beaumont ***@***.***> wrote: kubectl seems to throw an error if the namespaces disagree so that won't work. I guess the intended usage is to limit operations to a single NS, so it makes sense to throw an error. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2797?email_source=notifications&email_token=AASA4JFZTRL6G4ON5U64T2DRAGTDPA5CNFSM4KNEYAG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKHYVZQ#issuecomment-579832550>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASA4JA52HOMMCVGFQRZ3YLRAGTDPANCNFSM4KNEYAGQ> .

[2opremio]

For further reference https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable

Note that users may be already be setting it's value and that it may already contain a context and a default namespace (which should be overriden)