Add dynamic shell completion for unmanaged-cluster

[marckhouzam]

What this PR does / why we need it

This adds dynamic shell completion of cluster names for the different commands of unmanaged-cluster.
It also disables file completion for the cases where file names are not accepted.

Dynamic completion for flag values is not handled yet.

Which issue(s) this PR fixes

Related to vmware-tanzu/tanzu-framework#701

Describe testing done for PR

To test you should have unmanaged clusters available:

# Create a Running cluster
./unmanaged-cluster create c1

# Create a stopped cluster
./unmanaged-cluster create c2 && ./unmanaged-cluster stop c2

# Create a cluster that will have an Unknown status which will be named kind-c1
./unmanaged-cluster create c3 -e $HOME/.config/tanzu/tkg/unmanaged/c1/kube.conf

Setup completion for zsh:

autoload -Uz compinit;compinit # just in case completion was never setup

source <(./unmanaged-cluster completion zsh)
compdef _unmanaged-cluster unmanaged-cluster

or setup completion for bash:

# You need to have installed the bash-completion v2 package if you haven't already
source <(./unmanaged-cluster completion bash)

Now run some completion tests

# Completion of all cluster names
./unmanaged-cluster delete <tab>

# Completion of stopped or unknown clusters
./unmanaged-cluster start <tab>

# Completion of running or unknown clusters
./unmanaged-cluster stop <tab>

# No file completion or any other completion for the following
./unmanaged-cluster start c2 <tab>
./unmanaged-cluster stop c1 <tab>
./unmanaged-cluster delete c1 <tab>
./unmanaged-cluster list <tab>
./unmanaged-cluster config <tab>
./unmanaged-cluster create <tab>

Special notes for your reviewer

New package
I've created a new package completion and completely isolated the completion code in it. This is the approach that was requested for kubectl. For helm however, I chose to keep the completion code in the same file as the rest of the command (e.g., in configure.go for the configure command). The advantage of keeping the completion with the rest of the code is that I find it reduces the risk of forgetting to update it when something changes. What do we want for TCE?

Completion descriptions
Cobra allows to add descriptions to each completion. It aims to help the user make a decision more easily.
Choosing a good description often requires some experience with the product so I would particularly like your input.

I chose to add the status and provider, but it may not be useful, or if it is, we could revisit the output format. I currently don't like the format I chose:
zsh: cluster1 -- status: Running - provider: kind
bash: cluster1 (status: Running - provider: kind)

[stmcginnis]

The advantage of keeping the completion with the rest of the code is that I find it reduces the risk of forgetting to update it when something changes. What do we want for TCE?

I like the idea of keeping it with the code so there's less chance it will be overlooked. No strong feelings either way though, so I'm good with whatever the team decides.

Will check this out tomorrow. Thanks!

[jpmcb]

This public API entrypoint needs a comment

[jpmcb]

It also seems that this assumes that DeleteCmd, StartCmd, and StopCmd have been initialized ontop of the root command. Might be worth mentioning that in a comment

[jpmcb]

Nit: as far as code style, I don't think we usually do comments after a line

[jpmcb]

This could take quite some time; for example, with 3 minikube based clusters, we'd essentially be making 3 calls out to minikube profile to load up all the clusters info for the manager. Even with one default cluster in my testing, tabbing took a good 1-2 seconds

Is it necessary that we introspect the status of a cluster? In my opinion, for completions, it's enough that that tanzu.List returns a list of clusters it knows about on disk. I don't think we need to load up the manager for each cluster in order to only return valid clusters. For example, it'd still be valid to return a cluster that has status Unknown that failed to provision when doing unmanaged-cluster rm

[jpmcb]

I like the idea of keeping it with the code so there's less chance it will be overlooked. No strong feelings either way though, so I'm good with whatever the team decides.

Also no strong feelings, but I think I'd also prefer it to stay next to the command initialization code. It'd be easy to just call Setup() without knowing what it's doing or what conditions it assumes are present.

[github-actions]

This PR is being marked stale due to a period of inactivty. If this PR is still relevant, please comment or remove the stale label. Otherwise, this PR will close in 30 days.

[github-actions]

This PR was closed because it has been stalled for 30 days with no activity. If this PR is still relevant, please re-open a new PR against main.