Decide whether to retire the logdy role now that ward retired the disk+logdy workflow #473

Closed
opened 2026-07-05 03:34:12 +00:00 by coilysiren · 3 comments
Owner

Follow-up from #424.

Upstream ward has retired the disk+logdy workflow in favour of the local SigNoz path:

  • ward#510 added a detached docker wait exit-waiter so a closed run drains shortly after exit, keep-10 demoted to a backstop. This resolved the original #424 timing complaint on the producer side.
  • ward's default sink is now WARD_AGENT_SINK=signoz, which ships the whole run to the local SigNoz and persists nothing to disk. Infrastructure sets no WARD_AGENT_SINK, so on the fleet default ~/.ward/agent-logs/ is empty and the logdy role watches a tree that is never populated. logdy only shows anything when an operator opts into WARD_AGENT_SINK=disk (or both).

#424 corrected the infrastructure docs to state this honestly (logdy is now the opt-in disk-sink viewer, not the default agent-log surface). This issue is the deferred product decision it flagged:

Options

  • Retire the logdy role entirely (drop logdy_enabled from group_vars/mac.yml, remove the role), matching ward, and lean on the local signoz role as the sole agent-log viewer. Cost: the signoz role is a heavy opt-in 5-container stack (off by default), so macs lose the cheap loopback viewer.
  • Keep logdy as the lightweight disk-sink viewer for operators who set WARD_AGENT_SINK=disk, and additionally converge a default WARD_AGENT_SINK (e.g. both) so the tree is actually populated. Otherwise the role stays converged-but-empty on the default.
  • Keep the role but disable it fleet-wide (logdy_enabled: false) until someone needs the disk sink.

The wrong call here is cheap to undo (a role toggle), but it is a real fork about how macs view agent runs, so it is left for Kai rather than decided inside a doc-accuracy issue.

Refs: ward#510, ward#363, #421, #424.

Follow-up from #424. Upstream ward has **retired the disk+logdy workflow** in favour of the local SigNoz path: - `ward#510` added a detached `docker wait` exit-waiter so a closed run drains **shortly after exit**, keep-10 demoted to a backstop. This resolved the original #424 timing complaint on the producer side. - ward's default sink is now `WARD_AGENT_SINK=signoz`, which ships the whole run to the local SigNoz and persists **nothing** to disk. Infrastructure sets no `WARD_AGENT_SINK`, so on the fleet default `~/.ward/agent-logs/` is **empty** and the logdy role watches a tree that is never populated. logdy only shows anything when an operator opts into `WARD_AGENT_SINK=disk` (or `both`). #424 corrected the infrastructure docs to state this honestly (logdy is now the opt-in disk-sink viewer, not the default agent-log surface). This issue is the deferred **product decision** it flagged: **Options** - **Retire the logdy role** entirely (drop `logdy_enabled` from `group_vars/mac.yml`, remove the role), matching ward, and lean on the local `signoz` role as the sole agent-log viewer. Cost: the `signoz` role is a heavy opt-in 5-container stack (off by default), so macs lose the cheap loopback viewer. - **Keep logdy** as the lightweight disk-sink viewer for operators who set `WARD_AGENT_SINK=disk`, and additionally converge a default `WARD_AGENT_SINK` (e.g. `both`) so the tree is actually populated. Otherwise the role stays converged-but-empty on the default. - **Keep the role but disable it fleet-wide** (`logdy_enabled: false`) until someone needs the disk sink. The wrong call here is cheap to undo (a role toggle), but it is a real fork about how macs view agent runs, so it is left for Kai rather than decided inside a doc-accuracy issue. Refs: `ward#510`, `ward#363`, #421, #424.
coilyco-ops added
P4
and removed
P3
labels 2026-07-10 08:59:55 +00:00
Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-infrastructure-473 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-10T12:35:48Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)
  • Resolved: coilyco-flight-deck/infrastructure#473 · branch issue-473 · harness codex · workflow direct-main
  • Run: engineer-codex-infrastructure-473 · ward v0.580.0 · dispatched 2026-07-10T12:35:48Z
  • Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.580.0).

— Codex, via ward agent

<!-- ward-agent-reservation --> WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-infrastructure-473` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T12:35:48Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/infrastructure#473` · branch `issue-473` · harness `codex` · workflow `direct-main` - **Run:** `engineer-codex-infrastructure-473` · ward `v0.580.0` · dispatched `2026-07-10T12:35:48Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.580.0). </details> </details> <!-- ward-agent-signature --> — Codex, via `ward agent`
Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-infrastructure-473 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-10T12:50:09Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)
  • Resolved: coilyco-flight-deck/infrastructure#473 · branch issue-473 · harness codex · workflow direct-main
  • Run: engineer-codex-infrastructure-473 · ward v0.580.0 · dispatched 2026-07-10T12:50:09Z
  • Comment thread: 0 included in the pre-flight read, 1 stripped (ward's own automated comments).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.580.0).

— Codex, via ward agent

<!-- ward-agent-reservation --> WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-infrastructure-473` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T12:50:09Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/infrastructure#473` · branch `issue-473` · harness `codex` · workflow `direct-main` - **Run:** `engineer-codex-infrastructure-473` · ward `v0.580.0` · dispatched `2026-07-10T12:50:09Z` - **Comment thread:** 0 included in the pre-flight read, 1 stripped (ward's own automated comments). - stripped: @coilyco-ops (2026-07-10T12:35:49Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.580.0). </details> </details> <!-- ward-agent-signature --> — Codex, via `ward agent`
Member

WARD-OUTCOME: done

details

workflow: direct-to-main; review summary: review gate skipped by ~/.ward/config.yaml default

Retrospective: kept the role, but disabled it fleet-wide to match the retired disk+logdy path.
Confidence: high.
Surprises: pre-commit needed a writable UV Python cache/install dir in this container.
Follow-ups: none.

WARD-OUTCOME: done <details><summary>details</summary> workflow: direct-to-main; review summary: review gate skipped by ~/.ward/config.yaml default Retrospective: kept the role, but disabled it fleet-wide to match the retired disk+logdy path. Confidence: high. Surprises: pre-commit needed a writable UV Python cache/install dir in this container. Follow-ups: none. </details>
Sign in to join this conversation.
No description provided.