Improve the ability to switch the Tanzu supervisor cluster address (TCLI_SERVER env var)

[crackitty]

Problem

Currently, we can set the TCLI_SERVER env var to hold the address of the supervisor cluster and from there we can find the namespaces it owns and on to the clusters under each namespace.

If we want to switch to another supervisor, maybe located a different physical datacenter for example, that manages another set of namespaces and clusters, we currently update the value of the TCLI_SERVER env var.

Once we change this, then we are fixed to that new supervisor. To switch back, we need to update that env var again.

It would be nice if there was a command line option to set the supervisor, instead of editing the env var directly.

Proposal

Manage the list of supervisors similar to how kubectl manages its contexts, possibly. Since the list of supervisors is not something we can request from a server, we would need to manage it locally in some file on disk. Possibly under a folder like ~/.tcli where we can store a list of supervisor addresses.

Bonus

It would also be nice if we could integrate with tools like fzf so we could interact with the supervisors, namespaces and clusters in the same way we can with kubectx and kubens.

[amimof]

It would like to avoid having to declare a configuration file for tcli, all though I can see the benefits of it. I wonder if it can be solved without one. For example we can append an index to the current set of env vars and pass the index as a cmd line argument to tcli. For example

Declare the different environments

export TCLI_SERVER_0=https://supervisor.got.local
export TCLI_USERNAME_0=bob
export TCLI_PASSWORD_0=mypassword
export TCLI_SERVER_1=https://supervisor.sto.local
export TCLI_USERNAME_1=alice
export TCLI_PASSWORD_1=anotehrpassword

Specifcy which environment you want to use with the -e flag

# Login to the supervisor cluster #1
tcli login -e1
# Login to child clusters in supervisor #0
tcli login -e0 prod-cluster test-cluster some-other-cluster

[crackitty]

That's interesting. That might be a viable way to handle it without having the need to create config files.