default-context and default-namespace not working as intended?

[MisterTimn]

Describe the bug
For me, kcd and knd are not working properly and I also don't see how they should work?

Kubesess prepends the active kubeconfig from kubesess/cache to the $KUBECONFIG env variable, default-context should work across different shells but when I create a new one it defaults to the first in the list.

Because to persist the list of configs you add it to .bashrc or .zshrc, creating a new shell reinitializes the KUBECONFIG variable, so the prepended config is lost.

I also tried using option 2 of using multiple config files as described in readme (all config plain in .kube folder and let kubesess handle it, but I still get the same issue.

So it seems to me that one should add something default setting of KUBECONFIG in .zshrc to get a working default context no?

Something like

export KUBECONFIG=$HOME/.kube/cache/kubesess/$(kubesess -c context):$HOME/.kube/config

which doesn't work because cache only gets used when you set a namespace.

Am I missing some environment variable which kubesess sets pointing to the default context/namespace?

To Reproduce

1. kcd and choose a context
2. open new shell (done in tmux, or new terminal window)
3. Check current context and see that it is not the one you just defaulted to

Expected behavior
When setting default context, all new shells will default to this context

Screenshots

Desktop (please complete the following information):

• OS: Fedora
• Version 2.0.1

[Ramilito]

Hmmm....I'm not at home right now to test this out but do you not have a default yaml under .kube/config? Sort of a master config file?

If not, how does it work for you to set context when using kubectl? If you run this command: kubectl config use-context <CONTEXT>?

The idea (if there is no bug), is that we assume you have a default .kube/config as the base of your $KUBECONFIG env var, but if you don't have the variable set we are supposed to handle that as well.

My confusion is mostly because we actually avoid changing any files that kubesess doesn't own (.kube/kubesess/) and use kubectl to set the default context/namespace.

My assumption is that if the above command works, it should work for us as well since that's how we set it.

[MisterTimn]

I ported over from using kubectx and previously I just had all my various kubeconfig files in a directory .kube/configs and I set my KUBECONFIG like this:

export KUBECONFIG=$(for file in $(find ~/.kube/configs -type f); do echo -n ":$file"; done)

But even when I have a file at .kube/config and set my KUBECONFIG like this:

export KUBECONFIG=$HOME/.kube/config$(for file in $(find ~/.kube/configs -type f); do echo -n ":$file"; done)

I get the same result, using kcd then starting a new shell the default context is not persisted.

I can switch with kubectl config use-context just fine and kubectl config view shows me the flat merged kubeconfig with the correct current context set.

[Ramilito]

Does the change persist between shell when you do kubectl use-context?

[MisterTimn]

Yes using use-context it persists across shells. Should kcd alter the master config? Cause in my knowledge that's the only way it could persist a default config.

❯ bat ~/.kube/config | grep current-context
current-context: devops-admin
❯ kcd devops-team0
❯ bat ~/.kube/config | grep current-context
current-context: devops-admin
❯ k config use-context devops-team0
Switched to context "devops-team0".
❯ bat ~/.kube/config | grep current-context
current-context: devops-admin

[Ramilito]

I have a fix for your use case but want to work on it a bit more since my idea for the auto include configs won't work well with it.

The problem (with the fix) is that it would require everyone to have a similar env variable as you have .

Will try to get it fixed today!

[Ramilito]

I did not have time to do it the proper way, this should work for you I think, if it doesn't just reopen this issue!

[MisterTimn]

Thank you very much. I'll check it out as soon as there's a release. Or if you want I can test it from source? Just unsure as to how I should build and test the tool locally.

[Ramilito]

It's released!

[MisterTimn]

Verified that it's working here as well, many thanks!