Errors when versioner can't reach k8s server

[mrzenioszeniou]

👋 I'm on Apple silicon running macOS Monterey v12.1

I just switched from Docker Desktop to Rancher Desktop which –unless I'm mistaken– ships with kuberlr. When running kubectl commands while Rancher Desktop is not running and my context is set to rancher-desktop I get the following followed by the output I'd normally expect from kubectl:

I0201 12:38:43.267831   20246 versioner.go:58] Get https://127.0.0.1:6443/version?timeout=5s: dial tcp 127.0.0.1:6443: connect: connection refused

After switching contexts to a GCP cluster in which I'm authenticated, I get the following instead:

I0201 12:50:21.309898   20445 versioner.go:58] no Auth Provider found for name "gcp"

Apart from the printed errors, the underlying kubectl binary works as expected. After the errors I get the expected output from it.

[jandubois]

After switching contexts to a GCP cluster in which I'm authenticated, I get the following instead:

This is a separate problem, and you should file a separate issue for it.

[jandubois]

Sorry, I put the comment in because I wanted to add more suggestions about the failure mode when the cluster is not available, but it looks like kuberlr is just displaying the warning on stderr, but otherwise executes the command just fine.

The warning is ugly when you e.g. want to source kubectl completions in your shell profile, when the cluster may not be reachable. But that can be "fixed" by redirecting the error stream.

[mrzenioszeniou]

This is a separate problem, and you should file a separate issue for it.

Sure, done 👉 #19

Still, the warning seems out of place for certain commands, such as completion and version.

[jsoref]

@jandubois: for basic completion, the system really shouldn't reach out, it results in a really bad startup experience: kubernetes/kubectl#1247

If it really wants to be clever, it can cache the answer for each cluster and...

[bkmeneguello]

I think there are two problems, the first is the stdout pollution with unwanted messages, which is fixed by my PR. The other one is the delay introduced by the timeout. As a workaround it's possible to reduce the timeout value in the config. The caching you proposed seems to be dangerous because it doesn't work in the first request and may fail if the service becomes available.

[jsoref]

I haven't looked in detail at how kubectl and friends do completion, but it's generally the case that one can write completion at levels.

This means that generating completion for kubectl should only list all possible top level verbs. It shouldn't research anything related to subverbs.

For kuberlr, that means it can either cache a list of all known kubernetes cluster versions and provide the union of all top level kubectl verbs for all clusters, or it can provide the union of all top level kubectl verbs for some range of versions of kubectl.

When someone types:

kubectl⇥ The completion should offer things like

• kubectl config
• kubectl get
• kubectl run
• kubectl exec

If one confirms kubectl exec and then presses ⇥, then it'd be reasonable to ask for new completion for that command at that time, and that can be done by talking to the correct version of kubectl (namely the current one for the current context).

Note that a 5s timeout for something that is likely to be added to a user's profile startup script is really unacceptable. (It's slightly better than a 30s timeout, but, ...)

You can simulate this pain by adding a sleep 5 to your startup script and try using terminals for a day.