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 MetalLB CRD wait in post-install-prep fails without saying why #3714
Two of the wait constructs in hack/e2e-post-install-prep.sh print a line when they give up. The third does not.
Lines 141 and 142:
echo"[post-install-prep] waiting for MetalLB CRDs"
timeout 300 sh -ec 'until kubectl get crd ipaddresspools.metallb.io l2advertisements.metallb.io >/dev/null 2>&1; do sleep 2; done'
On elapse timeout exits 124, the set -e at the top of the script aborts, and nothing between those two events writes anything. The last line in the log is the one announcing the wait, and the caller then prints that the script failed. A reader gets the phase and no reason.
The contrast sits in the same file. The linstor waits print which object they were waiting for and for how long. The LINSTOR node wait prints its own message plus the endpoints and the pods of the namespace. Only this one is silent, and it is silent in the state that matters: the CRDs are absent, which means the operator that installs them did not get that far, and nothing in the log distinguishes that from the CRDs being late.
The >/dev/null 2>&1 inside the loop is correct and should stay. kubectl get crd on a CRD that does not exist yet is the ordinary case here, and printing it every two seconds for five minutes would bury everything else. What is missing is a line on the way out, and the state of the thing being waited for at that moment.
Not established: I have not seen this wait time out in a run. I read it out of the code while working on the waits above it.
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…