forgejo runner pinned to offline kai-desktop-tower-wsl - docker-label CI queue starves #312

Open
opened 2026-06-12 11:15:30 +00:00 by coilysiren · 1 comment
Owner

eco-app CI run #3 (and likely all docker-label jobs) sits in "Waiting to run" indefinitely. Tailscale shows the runner host offline:

  • kai-desktop-tower-wsl - offline, last seen 6 days ago
  • kai-desktop-tower - offline, last seen 6 days ago
  • kai-tower-3026 / kai-tower-3026-wsl - active

The forgejo runner StatefulSet is deliberately pinned to kai-desktop-tower-wsl (per docs/k3s-deploy-notes.md, to keep DinD bridge churn off kai-server). With the tower replaced by kai-tower-3026, the pin is stale: runner pods cannot schedule and the queue starves.

Fix path:

  1. Join kai-tower-3026-wsl to the k3s cluster (if not already) and repin the runner StatefulSet's nodeSelector to it.
  2. Clear any stale local-path PVCs from the old node so the StatefulSet can recreate them (known trap in the deploy notes triage tree).
  3. Update docs/k3s-deploy-notes.md mentions of kai-desktop-tower-wsl.

Found while shipping the first eco-app rollout (2026-06-12); the rollout proceeded by building the image on kai-server directly.

eco-app CI run #3 (and likely all docker-label jobs) sits in "Waiting to run" indefinitely. Tailscale shows the runner host offline: * `kai-desktop-tower-wsl` - offline, last seen 6 days ago * `kai-desktop-tower` - offline, last seen 6 days ago * `kai-tower-3026` / `kai-tower-3026-wsl` - active The forgejo runner StatefulSet is deliberately pinned to `kai-desktop-tower-wsl` (per docs/k3s-deploy-notes.md, to keep DinD bridge churn off kai-server). With the tower replaced by kai-tower-3026, the pin is stale: runner pods cannot schedule and the queue starves. Fix path: 1. Join `kai-tower-3026-wsl` to the k3s cluster (if not already) and repin the runner StatefulSet's nodeSelector to it. 2. Clear any stale `local-path` PVCs from the old node so the StatefulSet can recreate them (known trap in the deploy notes triage tree). 3. Update docs/k3s-deploy-notes.md mentions of kai-desktop-tower-wsl. Found while shipping the first eco-app rollout (2026-06-12); the rollout proceeded by building the image on kai-server directly.
Author
Owner

Update from the eco-app rollout (same day): the queue drained itself before any repin. kubectl get nodes during the rollout showed the cluster is now single-node (kai-server only) - the tower node is not in the cluster at all - and forgejo-runner-0 / forgejo-runner-1 were Running on kai-server, ~7 minutes old with 3 restarts, right before eco-app CI run #3 went green and published the image.

So the original framing (stale nodeSelector pin to kai-desktop-tower-wsl) does not match the live cluster: either the pin was already removed, or the StatefulSet tolerates kai-server now. What remains of this issue:

  1. eco-app run #3 sat queued ~25+ minutes before the runner pods (re)started - find what restarted them and whether pickup latency like that will recur.
  2. The runners on kai-server is exactly what docs/k3s-deploy-notes.md warns about (DinD bridge churn racing kube-proxy on kai-server). Either re-home them to kai-tower-3026-wsl by joining it to the cluster, or consciously accept the kai-server placement and update the notes.
  3. Update the kai-desktop-tower-wsl references in docs/k3s-deploy-notes.md to the 3026 tower either way.
Update from the eco-app rollout (same day): the queue drained itself before any repin. `kubectl get nodes` during the rollout showed the cluster is now **single-node (kai-server only)** - the tower node is not in the cluster at all - and `forgejo-runner-0` / `forgejo-runner-1` were Running **on kai-server**, ~7 minutes old with 3 restarts, right before eco-app CI run #3 went green and published the image. So the original framing (stale nodeSelector pin to kai-desktop-tower-wsl) does not match the live cluster: either the pin was already removed, or the StatefulSet tolerates kai-server now. What remains of this issue: 1. eco-app run #3 sat queued ~25+ minutes before the runner pods (re)started - find what restarted them and whether pickup latency like that will recur. 2. The runners on kai-server is exactly what docs/k3s-deploy-notes.md warns about (DinD bridge churn racing kube-proxy on kai-server). Either re-home them to `kai-tower-3026-wsl` by joining it to the cluster, or consciously accept the kai-server placement and update the notes. 3. Update the kai-desktop-tower-wsl references in docs/k3s-deploy-notes.md to the 3026 tower either way.
coilyco-ops added
P3
and removed
P2
labels 2026-07-10 09:00:12 +00:00
Sign in to join this conversation.
No description provided.