Kind: `kind get clusters` should return exit code 1 if no clusters exist

[jimangel]

• kind get clusters
• echo $?

Result: 0
Expected Result: 1

This would help with config management tools (if response code == 1; then create cluster). Also open to alternative suggestions if there's a better way.

[alejandrox1]

Hi @jimangel , non-zero exit codes denote that an error occurred and having no kind clusters in your machine is not an error.
A better way to check if you have a kind cluster running is to read the output from kind get clusters if there is a cluster then you will get a non-empty string back indicating the number of clusters.

[BenTheElder]

Hmm what does kubectl / kops etc do in this case?

Not at a computer currently but will try to find out later. I would have thought lack of output would suffice or inspecting if the Kubeconfig exists and there are indeed nodes?

We may also want some kind of structured output option in the future. 🤔

[neolit123]

i concur with @alejandrox1 's comment; it's not a CLI error.

We may also want some kind of structured output option in the future.

yes, machine readable output (e.g. JSON) should be the preferred way to handle such scenarios.

[alejandrox1]

Hmm what does kubectl / kops etc do in this case?

With kubectl, if for example you're trying to list nodes, the cli hangs and eventually errors out:

$ kubectl get no
the server doesn't have a resource type "no"

 $ echo $?
1

The again the cli is making a requests which fails.

Something closer to this issue would be listing the available contexts:

$ kubectl config view -o jsonpath='{.contexts[*].name}'

$ echo $?
0

[jimangel]

Great points! I also like the idea of checking if the kubeconfig exists since that would be unique with the name. Thanks @BenTheElder

We may also want some kind of structured output option in the future.

+1

[BenTheElder]

SGTM, let me know how that goes!
It might also be worth trying to query something like kubectl get no if the config does exist, the node names are also currently guaranteed to match the container name and the container's host name, which I believe we've documented somewhere and I'd like to keep true.