point dev.quant/prod.quant vhosts at nuke workers

[bborbe]

What

Repoints the dev.quant and prod.quant nginx vhosts on hz.hetzner-1 from the dead backend_servers upstream to the per-env nuke workers.

Already applied to the live host (item-scoped bw apply + nginx -t && systemctl reload) — this PR brings master in line with what is running.

Why

Both hosts served 503 no available server since the quant to nuke migration:

'backend_servers': ['172.16.90.6', '172.16.90.7', '172.16.90.9']

Those are the OLD quant masters nuke-k3s-master-0/1/2 (LAN 192.168.178.38/.39/.40), all decommissioned — so nginx had no healthy peer. The root quant vhost had already been migrated to http://192.168.178.44; its own comment recorded that the other two were left behind:

"Migrated off the old backend_servers upstream (still used by dev.quant/prod.quant trading UIs)."

Targets

vhost	proxy_pass	node
prod.quant	http://192.168.178.44	nuke-k3s-prod-worker-0
dev.quant	http://192.168.178.34	nuke-k3s-dev-worker-0

Worker, not master: the k3s svclb-traefik DaemonSet reports DESIRED=1 on each 2-node cluster because it does not tolerate node_type=master:NoSchedule. Nothing listens on the masters, so pointing there would 503 exactly as before. traefik's LoadBalancer EXTERNAL-IP confirms it advertises only the worker.

Both LAN IPs are reachable over the VPN via existing ccd iroutes — nuke-k3s-prod-worker-0 (vpn 172.16.90.22) and nuke-k3s-dev (vpn 172.16.90.26). No OpenVPN change needed.

The second commit reverts part of the first

54cda91 also deleted the now-unreferenced backend_servers upstream; fafc0ec puts it back. bundles/nginx/items.py only declares the upstreams.conf file item if upstreams: — so dropping the last upstream unmanages the file rather than deleting it, leaving a stale copy on the server listing three dead hosts. bw diff flagged this as an unexpected upstreams.conf change; with the block restored the diff is exactly the two vhost files. Removing it properly needs a follow-up that also deletes the file, and the retained block now carries a comment saying so.

(Commit 54cda91's message still mentions dropping the upstream — superseded by fafc0ec.)

Verification

• bw diff -b master hz.hetzner-1 → exactly dev.quant.conf + prod.quant.conf
• bw apply --only <the two files> → 2 fixed, 0 failed, 379 skipped (no unrelated drift applied)
• nginx -t OK, reloaded
• Both hosts moved 503 → 404: upstream now reachable, traefik answering. The 404 is a separate missing-Ingress issue, fixed in bborbe/trading#247
• Root quant.benjamin-borbe.de unchanged (307 to Google OAuth)

[ben-s-pull-request-reviewer]

The review is straightforward. Single file change, clear intent, good comments. Let me compile the report.

Must Fix (Critical): None.

Should Fix (Important): None.

Nice to Have (Optional): None.

Notes: This is a pure infrastructure configuration change (nginx node definition in Python). The dev.quant vhost is pointed at the dev worker (192.168.178.34) and prod.quant at the prod worker (192.168.178.44), both via the VPN — consistent with how the root quant vhost already works. The comments are thorough and explain the backend_servers upstream retention (deliberate — dropping the last upstream unmanages the file instead of deleting it). LICENSE is present. No issues.

{
  "verdict": "approve",
  "summary": "Single-file infrastructure change: dev.quant and prod.quant nginx vhosts are migrated from the decommissioned backend_servers upstream to the nuke worker nodes directly (dev worker 192.168.178.34, prod worker 192.168.178.44). Comments are thorough and explain both the migration and why the now-unused backend_servers upstream block is intentionally retained.",
  "comments": [],
  "concerns_addressed": []
}