✨clusterctl: generate returns better error message in case there is no management cluster available

[ykakarap]

What this PR does / why we need it:
Adds better errors to clusterctl generate cluster command.
This PR also adds a few helper functions to help with detecting the state of the existing cluster.

With this PR if a user runs the following clusterctl generate command without a management cluster we get the following error:

New Error Message:

❯ clusterctl generate cluster test2 -i docker:v0.4.3 --flavor "development" --kubernetes-version "v1.22.1"          
Error: management cluster not available. Cannot auto-discover target namespace. Please specify a target namespace

Old Error Message:

❯ clusterctl generate cluster test2 -i docker:v0.4.3 --flavor "development" --kubernetes-version "v1.22.0"
Error: failed to get context "" from ["/home/kakaraparthy/.kube/config"]

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #5352

[fabriziopandini]

/retitle clusterctl: generate returns better error message in case there is no management cluster available

[fabriziopandini]

/retitle ✨clusterctl: generate returns better error message in case there is no management cluster available

[sbueringer]

last nit from my side

[k8s-ci-robot]

@ykakarap: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-cluster-api-apidiff-main	a4fe42f	link	false	/test pull-cluster-api-apidiff-main

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[sbueringer]

/lgtm

[fabriziopandini]

/lgtm

Wondering if we should wait after release before merging this 🤔

[sbueringer]

/lgtm

Wondering if we should wait after release before merging this 🤔

In this case I personally would prefer waiting until after the release.

[ykakarap]

/hold
until 1.0 release is out.

[vincepri]

Any reason to hold this? Seems a good improvement to me

[sbueringer]

My thinking was that we don't necessarily need it in v1.0.0 and we don't have enough time to see if it introduces any kind of flakiness. (although the chance of that is very low)

[ykakarap]

The chances of this introducing any flakiness is pretty low. Are there any other tests we can run to gain confidence that this did not introduce and unknown bugs or unexpected UX?

This is a good UX improvement for uses to try 1.0, would be nice to have in the 1.0 release.
However, it is okay if we do not include it as it is not blocking or critical.

[sbueringer]

Just to be clear. I don't have a strong opinion either way :). That was just why I wrote #5373 (comment). (We were also doing a bunch of manual testing with clusterctl locally yesterday with various upgrade scenarios with CAPD and CAPA)

[ykakarap]

/hold cancel
v1.0.0 release is out.

[fabriziopandini]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fabriziopandini

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [fabriziopandini]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment