You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
test(e2e): the post-install-prep wait loop discards kubectl stderr for its whole budget #3713
if kubectl wait"$@" --timeout="${remaining}s"2>/dev/null;then
Discarding stderr there is deliberate and half right. kubectl wait exits non-zero immediately when the object does not exist yet, and the loop is built to tolerate that rather than abort on it, so without the redirect a NotFound message would be printed every five seconds for the whole budget.
The other half is a permanent failure. A bad kubeconfig, an expired credential or an RBAC denial also makes kubectl wait exit non-zero immediately, and by exit status alone that is indistinguishable from "not created yet". The loop retries it for the full budget and then reports a timeout waiting for the object. The message names the object and the elapsed budget, so the symptom points at the cluster while the cause sits in the client.
What distinguishes the two lives in the text and not in the status: NotFound reads differently from Unauthorized, and both exit non-zero. A loop that wants to tolerate the first and fail fast on the second has to read the message rather than the code.
The cost is a wrong diagnosis rather than a missing one, which is why it is worth filing at all. Fifteen minutes of retrying an unauthorized client ends in a sentence about an object that was never the problem.
Not established: I have not observed this in a run. I read it out of the code, and I did not check whether any past failure in the suite was actually this.
Activity
fix(e2e): budget each linstor wait separately in post-install-prep (#…
fix(e2e): bound post-install-prep calls and make its failures name th…