status command should communicate better

[dhrp]

Some suggestions:

1. It should check the current configured cluster by default; There should be no need to specify which cluster to connect to if I already have a config set and selected. For example with export KUBECONFIG=/XYZ
2. When I do specify --hosting-cluster-kubeconfig= the help text is missing / should make clear that I should specify a file. (because in the documentation elsewhere you ask to use --config= and mean a context out of a config.
3. There seems to be no --config flag.. How would it then work if I do have a file with multiple contexts?

   ✗ kubectl nova help status
   check status of Nova
   
   Usage:
    novactl status [flags]
   
   Flags:
    -h, --help                                help for status
        --hosting-cluster-kubeconfig string   Nova Control Plane hosting cluster kubeconfig path
   

ps. I'm on:

kubectl nova --version
novactl version v0.6.0 (git: 141d6e91) built: 20230801122921

[hidalgopl]

Some suggestions:

1. It should check the current configured cluster by default; There should be no need to specify which cluster to connect to if I already have a config set and selected. For example with export KUBECONFIG=/XYZ
2. When I do specify --hosting-cluster-kubeconfig= the help text is missing / should make clear that I should specify a file. (because in the documentation elsewhere you ask to use --config= and mean a context out of a config.
3. There seems to be no --config flag.. How would it then work if I do have a file with multiple contexts?

   ✗ kubectl nova help status
   check status of Nova
   
   Usage:
    novactl status [flags]
   
   Flags:
    -h, --help                                help for status
        --hosting-cluster-kubeconfig string   Nova Control Plane hosting cluster kubeconfig path
   

ps. I'm on:

kubectl nova --version
novactl version v0.6.0 (git: 141d6e91) built: 20230801122921

Hey @dhrp , thanks for your feedback!

1. It's a bit tricky one, because status command needs to communicate with two clusters: cluster that hosts Nova Control Plane (--hosting-cluster-kubeconfig=...) and the Nova Control Plane itself (for this we assume it's a current context)
2. I agree, we need to better document this, thank you for pointing this out.
3. It's a good point. We need to re-think the UX of this --hosting-cluster-kubeconfig flag and give an option to use one kubeconfig file but specify two different contexts (Nova Control Plane one & hosting cluster one) cc @selvik

[murbans1]

At the moment the control plane kubeconfig is read from nova home dir, so we would just need to pass hosting cluster context. Reading this issue I see we need to either document nova home dir better too or stop using it.