Need a `KN_NAMESPACE` env variable to avoid repeating same namespace

[maximilien]

While restoring the e2e tests that use bash I realize that a pain point that users of kn will experience is having to repeat the same namespace when issuing many commands in a row---If that namespace is not the default namespace.

See the PR #183 or sample snippet here to illustrate:

# Listing 1
# Will create and delete this namespace and use it for smoke tests
export KN_E2E_SMOKE_TESTS_NAMESPACE=kne2esmoketests

kubectl create ns $KN_E2E_SMOKE_TESTS_NAMESPACE

./kn service create hello --image gcr.io/knative-samples/helloworld-go -e TARGET=Knative -n $KN_E2E_SMOKE_TESTS_NAMESPACE
sleep 5
./kn service get -n $KN_E2E_SMOKE_TESTS_NAMESPACE -n $KN_E2E_SMOKE_TESTS_NAMESPACE
./kn service update hello --env TARGET=kn -n $KN_E2E_SMOKE_TESTS_NAMESPACE
sleep 3
./kn revision get -n $KN_E2E_SMOKE_TESTS_NAMESPACE
./kn service get -n $KN_E2E_SMOKE_TESTS_NAMESPACE
...

A better option would be to have kn use KN_NAMESPACE env value as the namespace for commands if that's defined.

So above becomes cleanly:

# Listing 2
# Will create and delete this namespace and use it for smoke tests
export KN_NAMESPACE=kne2esmoketests

./kn service create hello --image gcr.io/knative-samples/helloworld-go -e TARGET=Knative
sleep 5
./kn service get
./kn service update hello --env TARGET=kn
sleep 3
./kn revision get
./kn service get
...

[duglin]

I'm not against a KN_NAMESPACE env var, but I'd like it if we also picked up the namespace from the kube config. So, order of processing would be:
1 - -n flag
2 - KN_NAMESPACE
3 - Namespace from kube config

Then if people are switching between kn and kubectl, setting just the kube one will work for both.

[maximilien]

Yup. That's reasonable.

[rhuss]

@maximilien that is already fixed with #36 and using an intial kubectl config use-context I don't see the need for a special KN_NAMESPACE. Just use the current context's namespace by default.

[maximilien]

Hmm, not clear. Maybe I need to understand context more.

Anyhow, maybe you can clarify. How would you convert the snippet above (listing 1) to look like the second one. That is avoid repeating the -n $KN_E2E_SMOKE_TESTS_NAMESPACE in each command. Is it create a context, create namespace. Make that default?

Remember -n is an option in all commands. I suspect most users will do what I listed above (listing 1). Thoughts?

[duglin]

I think he means:

# permanently save the namespace for all subsequent kubectl commands in that context.
kubectl config set-context --current --namespace=ggckad-s2

from: https://kubernetes.io/docs/reference/kubectl/cheatsheet/

will set it once for all future kubectl/kn commands.
One of the reasons I was (sort of) ok with KN_NAMESPACE is because I think trying to remember (or having to alias) that kubectl config cmd is asking too much :-) Why there isn't a KUBE_NAMESPACE env var.... I dunno.

[maximilien]

How is that a great user experience? At least creating a namespace with kubectl is easy: kubectl create ns blah

With the config/context scheme, the user has to be using context, understand them, and set it to use the namespace she has in mind. Then remember to change context or namespace of context when she wants to use a different namespace for a series of commands.

I don't see this as a great UX. Especially since we sprinkle -n option to all commands. If we also had a global context option then I could see that we are suggesting users to consider context. But AFAIK we don't.

Anyhow, I've said my .02.

[rhuss]

You can see the 'current context' like a current working directory. Every UNIX command happens in that context (ls, touch, cat), except when you use an absolute path (in our analogy when you use -n).

Except that changing the current context is a bit tedious (with kubectl config use-context <myns>) its exactly the same concept. There are tools like kubens which help here. OpenShift's project (which is the extension to a namespace) can be easily switched which oc project <news> (and that is done all the time).

Having a new mechanism to switch that context with a new env variable is not a good UX as is very implicit.

I agree that

export KN_NAMESPACE=e2e-test

is better than

kubectl config set-context $(kubectl config current-context) --namespace=e2e-test

as described here, but its also very implicit.

Maybe it's now time to introduce a ~/.kn config directory/file which may hold either a 'default_namespace' file which can be set with kn set default namespace=.... (this could e.g. also use for setting the default wait behaviour like with kn set default wait=false).

However, its also important to note, that when we rely on ~/.kube/config as in #172 we introduce a subtle dependency on Kubernetes client tooling (which I think kn might want to try to avoid). We have that already for authentication, not sure how much this is "acceptable".

[rhuss]

With the config/context scheme, the user has to be using context, understand them, and set it to use the namespace she has in mind. Then remember to change context or namespace of context when she wants to use a different namespace for a series of commands.

Isn't this the same when using an environment variable, so that you have to remember to change the environment variable when you want to use a different namespace ?

What I was suggesting is not to introduce a new context each time but to update the current context with the target namespace (like kubens does)

[duglin]

How about we add this:

kn set-namespace foo
# or
kn config namespace=foo
# which leave it open for other types of config options

then these can do the kubectl config set-context $(kubectl config current-context) ... under the covers in the case of setting the NS. Or when we're not setting the NS it sets some $HOME/.kn/config thingy as needed.

The point here for me is that it would be really nice if, as a user, I didn't have to set two different NS config options because I expect people to jump between kn and kubectl a lot.

[maximilien]

Any other opinions on this issue? I am happy to implement the last suggestion.

@rhuss @sixolet @cppforlife chime in if you feel strongly about alternative approaches.

[navidshaikh]

Once #172 is in, we'll just need to create and set the desired namespace once and we should be good. No need for another var for namespace reference.

[rhuss]

I think the issue is, how we can easily set the current namespace directly with kn and without extra help from kubectl or kubens.

So having a

kn set-namespace food

as an alternative to

kubectl config set-context $(kubectl config current-context) --namespace=foo

sound a good idea as long as both kn and kubectl work on the same config so that they always both use the same default namespace. Nothing would be more confusing than having kubectl another default namespace than kn.

[navidshaikh]

kn set-namespace food

This seems reasonable as long as the desired namespace is recorded in kubeconfig (and not in some env var).

[maximilien]

OK waiting on @sixolet and/or @cppforlife for chime in. I am cool with kn set-namespace food

Any other opinions?

---

FYI to all... Nǐ hǎo 网络你好 from Shanghai for KubeCon/CNCon where many internet things don't work :( but GitHub does :) Otherwise all good but expect odd delays in responses.

[maximilien]

OK still have not heard from @sixolet and @cppforlife on this. Any opinions?

Otherwise, I can cook up a PR for this. Though we should think about how to retrieve the namespace and removing it. So perhaps something like:

kn namespace set foo
default namespace set to "foo"

kn namespace get
default namespace is "foo"

kn namespace unset
default namespace is unset

kn namespace get
default namespace is not set

The other possibility, as suggested by @duglin is using a config command, so:

kn config namespace=foo
default namespace set to "foo"

kn config namespace
default namespace is "foo"

kn config namespace=
default namespace is unset

kn config namespace
default namespace is not set

This is a command config that operates on the ~\.kn\config.yaml file which I am also using for plugins---set and retrieve the plugin path.

I like 2 better due to plugin but happy to hear other voices.