kubie integration or ability to have isolated context

[jemag]

Is your feature request related to a problem? Please describe.
Currently changing the context within kubectl.nvim will change the overall context for kubectl.

Describe the solution you'd like
I would like to be able to isolate the context change to only happen within kubectl.nvim. This could be done through an integration with kubie or with its own setup.

I often keep my kubectl cli on a specific sandbox cluster, while using kubectl.nvim to explore and debug other clusters. However, currently my "default" cluster will continuously change due to context changes within kubectl.nvim.

Describe alternatives you've considered
Load kubie in a specific cluster before opening kubectl.nvim. However this has the problem that only this specific cluster will be available in kubectl.nvim context, so cannot easily change afterwards.

Additional context

[Ramilito]

Yeah I would love to have per session as well, there sort of already is since we use the kubectl proxy that persists the connection even if you would change the context (you can test it out using multiple nvim instances).
The simplest solution would be to adjust the change context command to just create a proxy using the --context flag instead of assuming the current context.

[Ramilito]

@mosheavni, @jemag If we make that change (to not actually change the context but instead always use that proxy), we should probably make it possible to persist that change some how, do you have any ideas how to make that UX wise?

[jemag]

most plugins seem to use ~/.local/state/nvim/{plugin-name} to store any state that should persist. Common pattern is to either have it stored in json or lua file. I think both approaches are valid.

I assume that the persisting would mean once a user change context within one kubectl.nvim instance, further newly created kubectl.nvim instances would use that same context?

[Ramilito]

most plugins seem to use ~/.local/state/nvim/{plugin-name} to store any state that should persist. Common pattern is to either have it stored in json or lua file. I think both approaches are valid.

I assume that the persisting would mean once a user change context within one kubectl.nvim instance, further newly created kubectl.nvim instances would use that same context?

I agree here, we already save the current session, history and other things in that place so we could add last_context as well to keep track of it and avoid actually changing the default context and instead using the kubectl proxy --context to specify what context we are connecting to.

There is no real problem implementation wise but rather UX wise. Do we want to offer a way to change the default context?
How confusing would it be if you open a kubectl.nvim session to a different context than your kubectl has? Or, close kubectl.nvim to find that your shell is using a different one?

[jemag]

I dont find it particularly confusing since I am used to that workflow, but that could indeed be the case for existing users.

Perhaps this behavior could simply be configured through an option? (i.e.: retain current behavior or have isolated context)

[Ramilito]

Maybe a combination of configuration and a toggle, the configuration could set the default value of the toggle?

#Configuration would be

persist_context_change = true

And then in the change context view we would have a way to change that for just that change, it's mostly that I feel that just having a configuration and force people to restart nvim might be annoying

[jemag]

sounds good to me

[Ramilito]

Just a FYI, I've written a tool that is similar to kubie called kubesess that works with this plugin as long as you don't change the context using the plugin, you can have different contexts at the same time.

PS. this is mostly to buy me some time to solve this issue :D