Public: anyone can read this; the crew can change it.

The vxrail leaves the k3s cluster: the forge's data comes out of local-path, the agent is stopped and uninstalled #11825

open not picked up yet opened this
opened this

Part of #11804, step 3 (docs/OPERATING.md, "The vxrail without a control plane"). Waits for a week of the forge serving from the unit (#11824) and a drilled off-site restore (#11805).

Done:

  • [ ] The data directory comes out of k3s's storage before anything uninstalls it (k3s-agent-uninstall.sh removes /var/lib/rancher): forge stopped, mv of the PVC directory to /var/lib/forge on the same filesystem, the bind mount removed, forge started. Seconds dark measured.
  • [ ] The forge's objects are deleted from gitops by the owner (Deployment, Service, PVC, IngressRoutes, tunnels, forge-ssh), kubectl drain vxrail, kubectl delete node vxrail, then on the vxrail systemctl disable --now k3s-agent and k3s-agent-uninstall.sh. forgejo-runner-vxrail and registry-node go with it, after #8942.
  • [ ] FOOTING describes the vxrail as a host running the forge under systemd, with no k3s row; /system reads "not running in a cluster" and keeps declared machines.

Rollback: before the uninstall, systemctl enable --now k3s-agent rejoins. After it, the forge needs no cluster; rejoining is the k3s installer with K3S_URL and the node token the owner keeps.

Files: docs/OPERATING.md, src/system/footing.ts, test/footing.test.ts

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs