Split from #34. After the five environment/harness layers were fixed in #35 (kind multi-arch import, missing kubectl, recycle-assertion name race, kobectl crate move, missing C toolchain), the vkobe smokes finally run — and expose a real behavior: the e2e-vkobe-etcd / e2e-vkobe-kine-sqlite pools sit at ready=0 leased=0 creating=0 queue=0 for 8+ minutes after operator install. The operator reconciles the pools (the #190 limits warning fires for them) but never creates a member; no 'creates paused: datastore degraded' lines are visible in the failure tail.
Evidence: run 29764413062 (vkobe-etcd, vkobe-kine), kind-logs artifacts kind-logs-29764413062-vkobe-* (operator logs + cluster dump).
Since vkobe is on hold (see how-it-works/runtime-strategy), #35 marks the vkobe legs continue-on-error — still executed and visible per-leg, but not failing the nightly/tag run — until this is picked up. The k3s (production) leg is green and remains run-failing.
Split from #34. After the five environment/harness layers were fixed in #35 (kind multi-arch import, missing kubectl, recycle-assertion name race, kobectl crate move, missing C toolchain), the vkobe smokes finally run — and expose a real behavior: the
e2e-vkobe-etcd/e2e-vkobe-kine-sqlitepools sit atready=0 leased=0 creating=0 queue=0for 8+ minutes after operator install. The operator reconciles the pools (the #190 limits warning fires for them) but never creates a member; no 'creates paused: datastore degraded' lines are visible in the failure tail.Evidence: run 29764413062 (vkobe-etcd, vkobe-kine), kind-logs artifacts
kind-logs-29764413062-vkobe-*(operator logs + cluster dump).Since vkobe is on hold (see how-it-works/runtime-strategy), #35 marks the vkobe legs
continue-on-error— still executed and visible per-leg, but not failing the nightly/tag run — until this is picked up. The k3s (production) leg is green and remains run-failing.