🐛 set hosting cluster context preference in kflex init

[pdettori]

Summary

• set hosting cluster context preference in kflex init
• use "hosting cluster context" instead of "initial context" to make more clear the role of such context

Related issue(s)

Fixes #255

[pdettori]

Need to merge #265 first

[MikeSpreitzer]

This looks good so far.

Does this address point 2 in #255 ?

[pdettori]

Re. point 2 in #255 - the question is how to set the hosting cluster context if it is not initially known when doing kflex ctx ?

[MikeSpreitzer]

@pdettori:

and the current context is the hosting cluster context

which can be tested by looking to see if the controlplanes resource exists.

[pdettori]

@MikeSpreitzer let me see if I understand your proposal - the idea is not to add a new command to set the hosting cluster context preference (in case is not set or wrong) but rather use kflex ctx to do that, by testing if indeed the current context has the controlplanes API resource and if yes, set the hosting cluster context preference to the current context, if not, the error message should guide the user to use kubectl config use-context to first set the context to the hosting cluster context and then run kflex ctx again.

[MikeSpreitzer]

@pdettori: yes

[MikeSpreitzer]

I think what I am saying is the natural confluence of two things that we already are telling users to expect: (A) kflex ctx sets the kubeconfig current context to the hosting cluster context and (B) if the kubeconfig extension is not present but the current context IS the hosting context then the kubeconfig extension will be written (this was already the case for kflex ctx $my_non_host_cp_name).

[pdettori]

@MikeSpreitzer point 2 in #255 has been addressed

[pdettori]

Thank you, fixed the type, will go ahead and merge now.