o2r packaging: one-time import of historical Agent Channel data into the packaged channels deployment

coilysiren commented

2026-06-02 23:23:25 +00:00

Owner

Part of #45. Depends on #47 (channels layer must be deployed with its own Postgres first).

Goal: one-time import of the historical Agent Channel data ("historical o2r runs") into the newly-packaged channels deployment. Kai: we only need to do this once - not a vendored seed, not a recurring tool.

What the data is / where it lives now

The historical runs are the existing Agent Channels + their events (kinds: spec, state, status, comms, log).
They live in the current channels backend's Postgres, reached today via the otel-a2a-relay-cli (o2r channel ...) against config base_url (default http://api, the tailnet sidecar). GET /agent-channel.
Confirmed live as of 2026-06-02: at least channels VUJD (Qwen/Ollama keep-alive) and TU7P (rdp-restore-kai-desktop-tower) OPEN; closed ones via o2r channel list --all.

Migration approach (preferred: DB-level)

pg_dump the channel tables from the current backend's Postgres -> restore into the #47 deployment's Postgres. Schema is the channels package SCHEMA constant, so source and target schemas match - preserves channel ids, event ordering, and timestamps.
Fallback (API-level) if direct DB access to the old store isn't available: walk o2r channel list --all + o2r channel events <id> on the source, re-POST /agent-channel + .../event against the new deployment. Note: API replay may re-stamp created_at/event times and mint new ids unless the channels API is extended to accept them - call that out before choosing this path.

Sequence

Stand up #47 (channels chart + Postgres) -> freeze writes on the old backend -> dump/restore -> repoint o2r base_url at the new deployment -> verify -> retire the old store.

Acceptance

After cutover, o2r channel list --all against the new deployment shows the same channels (open + closed) as the old backend, and o2r channel events <id> returns the same event history for a spot-checked channel.
Old backend can be retired with no channel-data loss.

Part of #45. Depends on #47 (channels layer must be deployed with its own Postgres first). **Goal:** one-time import of the **historical Agent Channel data** ("historical o2r runs") into the newly-packaged channels deployment. Kai: we only need to do this once - not a vendored seed, not a recurring tool. ### What the data is / where it lives now - The historical runs are the existing **Agent Channels + their events** (kinds: spec, state, status, comms, log). - They live in the **current channels backend's Postgres**, reached today via the `otel-a2a-relay-cli` (`o2r channel ...`) against config `base_url` (default `http://api`, the tailnet sidecar). `GET /agent-channel`. - Confirmed live as of 2026-06-02: at least channels `VUJD` (Qwen/Ollama keep-alive) and `TU7P` (rdp-restore-kai-desktop-tower) OPEN; closed ones via `o2r channel list --all`. ### Migration approach (preferred: DB-level) - `pg_dump` the channel tables from the current backend's Postgres -> restore into the #47 deployment's Postgres. Schema is the channels package `SCHEMA` constant, so source and target schemas match - preserves channel ids, event ordering, and timestamps. - **Fallback (API-level)** if direct DB access to the old store isn't available: walk `o2r channel list --all` + `o2r channel events <id>` on the source, re-`POST /agent-channel` + `.../event` against the new deployment. Note: API replay may re-stamp `created_at`/event times and mint new ids unless the channels API is extended to accept them - call that out before choosing this path. ### Sequence - Stand up #47 (channels chart + Postgres) -> freeze writes on the old backend -> dump/restore -> repoint `o2r` `base_url` at the new deployment -> verify -> retire the old store. ### Acceptance - After cutover, `o2r channel list --all` against the new deployment shows the same channels (open + closed) as the old backend, and `o2r channel events <id>` returns the same event history for a spot-checked channel. - Old backend can be retired with no channel-data loss.

coilysiren referenced this issue

2026-06-02 23:23:26 +00:00

Arch pivot: every o2r layer ships as an isolated unit (pkg + chart + container) published from this repo #45

coilysiren commented

2026-06-02 23:27:09 +00:00

Author

Owner

DB-level path verified — source store probed (read-only)

Connected to the old store via the DSN Kai supplied (postgresql://backend@backend-db/backend, reachable over tailnet) and ran SELECT-only probes. DB-level dump/restore is confirmed viable and trivial.

Schema parity: the live store's tables are exactly the packaged SCHEMA (channels/src/otel_a2a_relay_channels/router.py): agent_channels(id text, title, created_by, created_at, closed_at) and agent_channel_events(id bigint, channel_id->agent_channels CASCADE, kind, author, payload jsonb, created_at). No conversion needed - source schema == target schema.

What's there (as of 2026-06-02):

agent_channels: 6 rows - TU7P (open), VUJD (open), VHGC, DWUW, Q9WR, XCMG (closed). XCMG is "o2r CLI smoke test (safe to ignore)" - consider dropping it on import.
agent_channel_events: 72 rows (VHGC 44, DWUW 17, Q9WR 6, TU7P 2, VUJD 2, XCMG 1).
On-disk size: 256 kB. Trivial dump.

Critical scoping caveat: the old DSN points at a shared backend DB. Alongside the two channel tables it also holds documents, queue_jobs, sentinels, sql_tables (unrelated backend data). The migration must dump only agent_channels + agent_channel_events - never a whole-DB pg_dump.

Concrete migration (data-only, target schema pre-created by the channels app's SCHEMA):

pg_dump "$SOURCE_DSN" --data-only \
  -t agent_channels -t agent_channel_events \
  | psql "$TARGET_DSN"

pg_dump orders parent (agent_channels) before child (agent_channel_events), so the CASCADE FK is satisfied. Run once at #47 cutover; target is the packaged channels deployment's Postgres. Optionally DELETE FROM agent_channels WHERE id='XCMG'; post-import to drop the smoke-test channel.

Acceptance (unchanged): o2r channel list --all against the new deployment shows the same 6 (or 5 sans XCMG) channels; o2r channel events <id> matches for a spot-checked channel (e.g. VHGC's 44 events).

Source DSN host is a meaningful name (backend-db); resolved tailnet FQDN/IP are opaque and deliberately omitted here per SSM rules.

### DB-level path verified — source store probed (read-only) Connected to the old store via the DSN Kai supplied (`postgresql://backend@backend-db/backend`, reachable over tailnet) and ran SELECT-only probes. DB-level dump/restore is confirmed viable and trivial. **Schema parity:** the live store's tables are exactly the packaged `SCHEMA` (`channels/src/otel_a2a_relay_channels/router.py`): `agent_channels(id text, title, created_by, created_at, closed_at)` and `agent_channel_events(id bigint, channel_id->agent_channels CASCADE, kind, author, payload jsonb, created_at)`. No conversion needed - source schema == target schema. **What's there (as of 2026-06-02):** - `agent_channels`: **6 rows** - TU7P (open), VUJD (open), VHGC, DWUW, Q9WR, XCMG (closed). XCMG is "o2r CLI smoke test (safe to ignore)" - consider dropping it on import. - `agent_channel_events`: **72 rows** (VHGC 44, DWUW 17, Q9WR 6, TU7P 2, VUJD 2, XCMG 1). - On-disk size: **256 kB**. Trivial dump. **Critical scoping caveat:** the old DSN points at a **shared backend DB**. Alongside the two channel tables it also holds `documents`, `queue_jobs`, `sentinels`, `sql_tables` (unrelated backend data). The migration must dump **only** `agent_channels` + `agent_channel_events` - never a whole-DB `pg_dump`. **Concrete migration (data-only, target schema pre-created by the channels app's `SCHEMA`):** ``` pg_dump "$SOURCE_DSN" --data-only \ -t agent_channels -t agent_channel_events \ | psql "$TARGET_DSN" ``` pg_dump orders parent (`agent_channels`) before child (`agent_channel_events`), so the CASCADE FK is satisfied. Run once at #47 cutover; target is the packaged channels deployment's Postgres. Optionally `DELETE FROM agent_channels WHERE id='XCMG';` post-import to drop the smoke-test channel. **Acceptance (unchanged):** `o2r channel list --all` against the new deployment shows the same 6 (or 5 sans XCMG) channels; `o2r channel events <id>` matches for a spot-checked channel (e.g. VHGC's 44 events). Source DSN host is a meaningful name (`backend-db`); resolved tailnet FQDN/IP are opaque and deliberately omitted here per SSM rules.

coilysiren referenced this issue

2026-06-02 23:30:20 +00:00

o2r packaging: channels layer - runnable app shim + container + Postgres chart #47

coilysiren commented

2026-06-02 23:30:21 +00:00

Author

Owner

Cutover note: the new channels deployment is tailnet-only (see #47). The o2r base_url repoint after import must target the new service's tailnet address, never a public endpoint.

Cutover note: the new channels deployment is **tailnet-only** (see #47). The `o2r` `base_url` repoint after import must target the new service's tailnet address, never a public endpoint.

coilysiren referenced this issue

2026-06-02 23:40:18 +00:00

Arch pivot: every o2r layer ships as an isolated unit (pkg + chart + container) published from this repo #45

coilysiren added the

P3

label

2026-06-04 08:16:40 +00:00

coilysiren commented

2026-06-17 08:23:44 +00:00

Author

Owner

Backlog burndown 2026-06-17: closing low-priority (P3/P4) to bring the open count to a manageable level. Nothing lost — reopen if this resurfaces. Batch tag: burndown-2026-06.

Backlog burndown 2026-06-17: closing low-priority (P3/P4) to bring the open count to a manageable level. Nothing lost — reopen if this resurfaces. Batch tag: `burndown-2026-06`.

coilysiren

2026-06-17 08:23:44 +00:00

closed this issue
added the
burndown-2026-06
label

Rows
Columns

o2r packaging: one-time import of historical Agent Channel data into the packaged channels deployment #52

What the data is / where it lives now

Migration approach (preferred: DB-level)

Sequence

Acceptance

DB-level path verified — source store probed (read-only)