lair/quantus
2
0
Fork 0
Code Issues 5 Pull Requests Actions Packages Projects Releases Wiki Activity

Retire deploy-node and deploy-miner once the fork repos deploy themselves #4

New Issue
Open
opened 2026-09-03 09:23:48 +00:00 by grenade · 2 comments
grenade commented 2026-09-03 09:23:48 +00:00
Owner
Copy Link

The miner and node are now private forks on this Gitea (quantus/miner, quantus/chain) that will follow their own main branches, with the miner built as one fat binary carrying cubins for every card in the fleet. Each fork gains a deploy workflow (quantus/miner#8 and quantus/chain#2). Two deployers for one host is not acceptable: this repo pins a release version, the forks deploy main, and every run of either would flip the binary and restart the service. So this repo's deploy-node and deploy-miner jobs retire, and the fetch job with them.

What moves out

To quantus/miner To quantus/chain
deploy-miner job and its matrix (host, node, gpu_devices), unchanged in shape deploy-node job and its matrix (inner_hash, public_addr, rpc_expose, miners)
asset/systemd/quantus-miner.service, .sysusers.conf asset/systemd/quantus-node.service, .sysusers.conf
asset/firewalld/quantus-miner-metrics.xml asset/firewalld/quantus-node*.xml
asset/config/miner.env.tmpl asset/config/node.env.tmpl
the miner role of script/infra-setup.sh (sudoers quantus-miner_gitea_ci) the node role (quantus-node_gitea_ci, network key, credential read grants)
the miner sections of CLAUDE.md and readme.md (traps, measured facts) the node sections

The sudoers preflight in each deploy compares grants against the infra-setup.sh in the same repo, which is the reason the roles split rather than staying here: the deployer and its grant list must not be able to drift.

What stays

This becomes the fleet-level repo for the things that are not one component:

  • deploy-metrics: Prometheus scrape drop-in, Grafana dashboards (quantus.json, gpu.json), arena exporter. Gains the recording rules and the "Performance by build" row from quantus/miner#9.
  • nvidia-power-limit and nvidia-textfile units and the gpu role. Fleet-general, already noted in infra-setup.sh as belonging in a monitoring repo that does not exist yet.
  • The edge role (wss://quantus.internal), operator-run.
  • infra-setup.sh for the roles above, plus the shared gitea_ci user creation (idempotent, so all three repos creating it is harmless).
  • doc/wormhole-rewards.md and the reward-address guidance; the inner_hash values themselves move with the node matrix.
  • Issues #1, #2, #3 here are unaffected.

SCRAPE_NODES / SCRAPE_MINERS remain here and must agree with the two forks' matrices. validate metrics already asserts every quantus-* target is up, which is the drift check; note in each fork's matrix that adding a host means a scrape-target change here.

Sequence

  1. Fork repos land their deploy workflows in validate-only mode and run green against the hosts this repo deployed. No change here yet.
  2. On one day: disable fetch, deploy-node, deploy-miner here (remove the jobs, keep deploy-metrics and re-point its needs:), and flip both forks to deploy mode. Version pins NODE_VERSION / MINER_VERSION go with the jobs.
  3. After one clean cycle of both forks, delete the moved assets and script roles here and update readme.md / CLAUDE.md so the "source of infra truth" statement names the three repos and what each owns.
  4. Re-run the reduced infra-setup.sh here and the new ones in each fork so every host's sudoers matches its new deployer.

Not changing

The gitea_ci runner key, the RSYNC_SSH_KEY secret (copy it to the two forks, never regenerate), firewall scoping rules, the no-op-when-unchanged discipline, and the validate checks. All of that moves as-is; the point of this issue is ownership, not behaviour.

The miner and node are now private forks on this Gitea (`quantus/miner`, `quantus/chain`) that will follow their own `main` branches, with the miner built as one fat binary carrying cubins for every card in the fleet. Each fork gains a deploy workflow (quantus/miner#8 and quantus/chain#2). Two deployers for one host is not acceptable: this repo pins a release version, the forks deploy `main`, and every run of either would flip the binary and restart the service. So this repo's `deploy-node` and `deploy-miner` jobs retire, and the `fetch` job with them. ## What moves out | To `quantus/miner` | To `quantus/chain` | | --- | --- | | `deploy-miner` job and its matrix (`host`, `node`, `gpu_devices`), unchanged in shape | `deploy-node` job and its matrix (`inner_hash`, `public_addr`, `rpc_expose`, `miners`) | | `asset/systemd/quantus-miner.service`, `.sysusers.conf` | `asset/systemd/quantus-node.service`, `.sysusers.conf` | | `asset/firewalld/quantus-miner-metrics.xml` | `asset/firewalld/quantus-node*.xml` | | `asset/config/miner.env.tmpl` | `asset/config/node.env.tmpl` | | the miner role of `script/infra-setup.sh` (sudoers `quantus-miner_gitea_ci`) | the node role (`quantus-node_gitea_ci`, network key, credential read grants) | | the miner sections of `CLAUDE.md` and `readme.md` (traps, measured facts) | the node sections | The sudoers preflight in each deploy compares grants against the `infra-setup.sh` in the same repo, which is the reason the roles split rather than staying here: the deployer and its grant list must not be able to drift. ## What stays This becomes the fleet-level repo for the things that are not one component: - `deploy-metrics`: Prometheus scrape drop-in, Grafana dashboards (`quantus.json`, `gpu.json`), arena exporter. Gains the recording rules and the "Performance by build" row from quantus/miner#9. - `nvidia-power-limit` and `nvidia-textfile` units and the `gpu` role. Fleet-general, already noted in `infra-setup.sh` as belonging in a monitoring repo that does not exist yet. - The `edge` role (`wss://quantus.internal`), operator-run. - `infra-setup.sh` for the roles above, plus the shared `gitea_ci` user creation (idempotent, so all three repos creating it is harmless). - `doc/wormhole-rewards.md` and the reward-address guidance; the `inner_hash` values themselves move with the node matrix. - Issues #1, #2, #3 here are unaffected. `SCRAPE_NODES` / `SCRAPE_MINERS` remain here and must agree with the two forks' matrices. `validate metrics` already asserts every `quantus-*` target is up, which is the drift check; note in each fork's matrix that adding a host means a scrape-target change here. ## Sequence 1. Fork repos land their deploy workflows in `validate`-only mode and run green against the hosts this repo deployed. No change here yet. 2. On one day: disable `fetch`, `deploy-node`, `deploy-miner` here (remove the jobs, keep `deploy-metrics` and re-point its `needs:`), and flip both forks to deploy mode. Version pins `NODE_VERSION` / `MINER_VERSION` go with the jobs. 3. After one clean cycle of both forks, delete the moved assets and script roles here and update `readme.md` / `CLAUDE.md` so the "source of infra truth" statement names the three repos and what each owns. 4. Re-run the reduced `infra-setup.sh` here and the new ones in each fork so every host's sudoers matches its new deployer. ## Not changing The `gitea_ci` runner key, the `RSYNC_SSH_KEY` secret (copy it to the two forks, never regenerate), firewall scoping rules, the no-op-when-unchanged discipline, and the validate checks. All of that moves as-is; the point of this issue is ownership, not behaviour.
grenade commented 2026-09-03 10:15:32 +00:00
Author
Owner
Copy Link

One more reason to finish this cut-over promptly: while this repo's deploy still owns quantus-miner.service, any run of it (push to main, manual dispatch) that lands during a bench measurement on quantus/miner will find the unit stopped, conclude "nothing changed but the miner is down", and start it mid-window. That corrupts the measurement rather than breaking anything, and the harness's utilisation check only guards the start of a run. Until deploy-miner retires here, do not run this workflow while a bench run is in flight on the same host. After the cut-over the miner repo owns both the deploy and the bench and can serialise them under the same host lock.

One more reason to finish this cut-over promptly: while this repo's deploy still owns `quantus-miner.service`, any run of it (push to `main`, manual dispatch) that lands during a `bench` measurement on quantus/miner will find the unit stopped, conclude "nothing changed but the miner is down", and start it mid-window. That corrupts the measurement rather than breaking anything, and the harness's utilisation check only guards the start of a run. Until `deploy-miner` retires here, do not run this workflow while a bench run is in flight on the same host. After the cut-over the miner repo owns both the deploy and the bench and can serialise them under the same host lock.
grenade commented 2026-09-03 10:45:38 +00:00
Author
Owner
Copy Link

Step 2, miner half, done 2026-09-03: #6 merged after quantus/miner's deploy went green on both hosts from its main (quantus/miner actions/runs/19). This repo no longer ships the miner. SCRAPE_MINERS still lists benjy and quadbrat and the deploy triggered by #6 must show both miners up in validate metrics.

The mid-benchmark restart hazard noted above is gone with it: nothing here touches quantus-miner.service any more.

Remaining for this issue: the node half (quantus/chain#2), and step 3 (readme.md still carries the stale 4090 hashrate table; see quantus/miner#2 for the measured numbers).

Step 2, miner half, done 2026-09-03: #6 merged after quantus/miner's deploy went green on both hosts from its `main` (quantus/miner actions/runs/19). This repo no longer ships the miner. `SCRAPE_MINERS` still lists benjy and quadbrat and the deploy triggered by #6 must show both miners up in `validate metrics`. The mid-benchmark restart hazard noted above is gone with it: nothing here touches `quantus-miner.service` any more. Remaining for this issue: the node half (quantus/chain#2), and step 3 (`readme.md` still carries the stale 4090 hashrate table; see quantus/miner#2 for the measured numbers).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent-bot grenade
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: lair/quantus#4
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?