kinvolk/kube-spawn

KUBECONFIG not set when running with fish shell

Closed this issue · 9 comments

blixtra commented

kubectl get nodes does not work without manually setting the KUBECONFIG variable when using the fish shell.

Had to run export KUBECONFIG=/var/lib/kube-spawn/default/kubeconfig to get it working.

robertgzr commented

I don't think we set KUBECONFIG at all.

The README says:

To verify everything worked you can run:

$ export KUBECONFIG=/var/lib/kube-spawn/default/kubeconfig
$ kubectl get nodes
blixtra commented

In the Quick Start section, it does not say that.

We need to fix that.

robertgzr commented

Should setting it be part of up?

I don't think kube-spawn start should set it because we can run multiple clusters and it would always overwrite it for the most recent one.

alban commented

This is a matter of documentation because it's not possible for kube-spawn to set the environment variable of a parent process.

blixtra commented

There used to be a hint telling the user what to do. That has disappeared. I'd suggest we add it back. Otherwise I assume it's done for me.

dongsupark commented

@blixtra True. The hint about KUBECONFIG at the end of start has somehow disappeared.
I think that the message is indeed helpful. Let's bring it back.

alban commented

It was deleted in https://github.com/kinvolk/kube-spawn/pull/161/files#diff-df46f5e52ac4d342643dc4c045faee8aL131:

-       log.Println("Note: For kubectl to work, please set $KUBECONFIG to " + utils.GetValidKubeConfig())

When adding it back, please give a line that can be copy-pasted in the shell, such as:

log.Println("Note: For kubectl to work, please set $KUBECONFIG:")
log.Printf("export KUBECONFIG=%s\n", utils.GetValidKubeConfig())

It was very annoying to type this manually.

  • 👍1
alban commented

#233 does not seem to work properly (at least on @blixtra's computer)

dongsupark commented

@alban Right.
I saw too that the hint didn't get printed yesterday on @blixtra's computer, while it worked fine for me.

Now I've just realized the reason. It's cluster name. At the moment GetValidKubeConfig() only checks for the default cluster name, default, without caring about other custom cluster names. This was good enough before the v0.2 era, because default was then the only possible name. Though it's not true any more. As #233 was just a simple resurrection of the old function, it was not able to take care of such a case. We need to update GetValidKubeConfig() to take care of the cluster name.

I'll prepare a PR to fix that.