Better Error Reporting

[foundryserver]

Is your feature request related to a problem? Please describe.

I deployed k0s with NO cni enabled, as I installed cilium after the fact. The bootstrap reports "workers failed to be come ready". It should have been obvious to me that this should have been an expected response, when no cni has been bootstrapped.

If the config file has the cni disabled, then the boot strap should change how it determines a successful boot strap. Or at least post a warning as to by the ready state failed.

I had another bootstrap failure when there was two interfaces on the worker nodes, one for k8s and one for storage. Because I didn't spec a interface name, the bootstrap chose the wrong interface. Again no reporting that this was the case.

In short, I would like to have better failure reporting. However this distribution is one of the best I have used, and I am greatfull for all the hard work.

Describe the solution you would like

No response

Describe alternatives you've considered

No response

Additional context

No response

[jnummelin]

Are you deploying with k0sctl?

[foundryserver]

yes

[jnummelin]

Moving to k0sctl repo since it's more related to that

[jnummelin]

If the config file has the cni disabled, then the boot strap should change how it determines a successful boot strap. Or at least post a warning as to by the ready state failed.

We already support --no-wait flag which will not try to wait to see the workers getting to ready state. I do agree that maybe k0sctl could enable that automatically when custom CNI is in play as in this case we know it's unlikely the nodes will get to ready state by k0sctl and k0s itself. Unless one uses k0s helm extensions to deploy the CNI...

Because I didn't spec a interface name, the bootstrap chose the wrong interface. Again no reporting that this was the case.

Well, from k0sctl point of view there's no right and wrong interfaces. k0sctl can only make best guesses, which in this case were wrong. :D How did the wrong interface defaulting manifest in your use case? What failed and how? Just thinking if those symptoms could be something k0sctl could pick up and report to user.