option to overwrite `current-context`

[MichaelSp]

Instead of replacing the KUBECONFIG with a dynamically created config, sometimes I want to explicitly set the current-context in my existing KUBECONFIG. This would make a nice CLI option. Maybe something like switch --set-current-context or switch --keep-kubeconfig

[cedricmckinnie]

Great tool but this is a bit of a dealbreaker for my workflow because I tend to new open terminals often and I would like for kubeswitch to set the current-context in the kubeconfig to preserve the context set by switch. Also, some commands are erroring out when no kubecontext is set in the kubeconfig i.e.

$ switch --version
W0712 17:28:07.790609   94292 loader.go:223] Config not found: switch version v0.7.2
error: current-context is not set
switched to context "".

[lfrancke]

Another use-case for this would be for IDEs. I'd love IntelliJ to pick up whatever I currently selected but that will only work if the existing KUBECONFIG file is kept.

[lfrancke]

As there is not yet any established way of doing this: I'm happy to sponsor 50€ for whoever implements this. I can send the money via PayPal or in the EU send a SEPA payment.

I'd like to be able to make this the default behavior as well (as an option in switch-config I guess)

[tommy-heyde-olsen]

If I understand this problem correct, you:

1. want to be able to set a global current-context (equivalent to what happens inside ~/.kube/config)
2. Use the global current-context when starting up a new terminal.

If the above is true, I only see a solution where KUBECONFIG is set during start-up when the new terminal is started. This can only happen if we do something like:

KUBECONFIG=$(switch use-current-context)

In the shells profile or config file (eg. ~/.zprofile or ~/.zshrc).

This way the dynamic created config file can be injected into KUBECONFIG.

This means there would also need to be a switch set-current-context command that saves the shell's current context to a state file somewhere and makes sure that the dynamic created configuration file is flagged to not be deleted.

If my understanding is correct and you accept my proposed solution, I can take a jab at implementing it :)

[lfrancke]

I'm currently on holiday with limited access to a computer. And I'm only speaking for myself, I hope it aligns with the original intent.

I like the terminal window isolation of kubeswitch but it doesn't work everywhere.

So, I'd like the option of overriding the original KUBECONFIG (usually ~/kube/config) in addition to/instead of the temporary copy. The readme says

"kubectx directly modifies the kubeconfig file to set the current context. This has the disadvantage that every other terminal using the same Kubeconfig file (e.g, via environment variable KUBECONFIG) will also be affected and change the context."

For some use cases this "disadvantage" is exactly what I need though.

The original issue mentioned only updating "current-context" but that is only helpful if the context is already in the KUBECONFIG.

[tommy-heyde-olsen]

In ~/.kube/config we can link to a context by setting the clause current-context: <cluster-name>. This works across your terminals, because kubectl by default only looks at this file and deducts the current-context from this.

However with kubeswitch the KUBECONFIG environment variable is set in each individual terminal, pointing to a dynamic created file containing only this context. Contexts in kubeswitch comes from many sources (vault, gke, gardener, folders, etc), so there's not a clean way to reference the current terminals current-context anywhere that can be shared across terminals.

From my perspective it makes perfect sense to replicate the behaviour from kubectl config current-context in kubeswitch, however the implementation as I see it will have to be different.

[lfrancke]

But kubeswitch downloads/creates a kubeconfig even for these dynamic sources at some point, right?

I'd be fine with kubeswitch overriding my regular kube/config file to contain only the selected context I think.

As the original creator of this issue suggested, this could/should be behind a CLI flag. But it would be great if this could be made the default.

[danielfoehrKn]

want to be able to set a global current-context (equivalent to what happens inside ~/.kube/config). Use the global current-context when starting up a new terminal.

You could also use switch . which switches to the last (context, namespace) from the history. This works across stores. I use that a lot manually, but it might slow down your terminal startup.

The original author stated:

want to explicitly set the current-context in my existing KUBECONFIG.

If restricted to kubeconfigs originated from the filesystem, that should be simple (same behavior as kubectx). For other stores like Vault, it should be possible (UPDATE to vault). For stores like GKE and Gardener, setting the current-context makes no sense I think, as those kubeconfigs only have a single context for a single cluster.

Alternatively, one layer of abstraction (e.g a state file) could be used to map kubeconfig -> current_context. But that seems overly complicated.

But it would be great if this could be made the default.

I would like to avoid breaking changes. It could be a simple flag in the SwitchConfig file in addition to a CLI flag.

[lfrancke]

I'm sorry for the late reply, catching up after holiday.

switch . won't work for IntelliJ for example but good to know!

For stores like GKE and Gardener, setting the current-context makes no sense I think, as those kubeconfigs only have a single context for a single cluster.

I'm afraid I don't understand what you mean with this?

I would like to avoid breaking changes. It could be a simple flag in the SwitchConfig file in addition to a CLI flag.

Yes, sorry. That was poor phrasing on my part. I would like to be able to enable this by default but the "default" setting can be fals :)