swarm-controller: retry the legacy forge token sweep from the mint pass
The sweep ran once at startup and was never retried: a boot where store::connect or the roster read failed (e.g. the controller up before bao) left the tokens live until the next restart. It now runs off forge::agent_token::spawn's five-minute mint pass, reusing that pass's roster observation instead of a second store/roster read, so a failed first tick retries on the next one. Idempotent, so a re-run after a partial sweep deletes nothing extra. Drops the one-shot startup spawn; one call path. Also updates the forge.md and agent_token.rs docs that still said the legacy hyperhive-<seconds> tokens stay until manually removed. Refs #4644
This commit is contained in:
parent
23e0c313b8
commit
e9206505d4
4 changed files with 36 additions and 67 deletions
|
|
@ -59,8 +59,9 @@ most one. The agent fetches the token under its own store certificate into
|
|||
and `hive-forge`, the git credential helper, the `forge_notify` poller and
|
||||
the avatar sync read it from there, falling back to `<state>/forge-token`,
|
||||
the file hive-c0re wrote before. hive-c0re no longer creates agent users or
|
||||
mints agent tokens; the `hyperhive-<unix-seconds>` tokens it minted stay on
|
||||
the forge until removed.
|
||||
mints agent tokens. swarm-controller deletes the `hyperhive-<unix-seconds>`
|
||||
tokens it left behind, for each agent whose current `swarm-agent` token is
|
||||
live; `core`'s `hyperhive`-named admin token is never touched.
|
||||
|
||||
Two things live in the `agent-configs` Forgejo organization:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue