Evaluate ARA + NocoDB drift-grid pipeline (first self-host eval) #330

New issue

Closed

opened 2026-06-15 13:13:21 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-06-15 13:13:21 +00:00

Owner

Goal

Stand up the drift-grid pipeline so the rollout/backfill matrix is a materialized view of the ansible check, not a hand-curated list.

Pipeline (see #326 comment #10389 for the full reasoning)

ARA backend → PostgreSQL on kai-server. ARA is an ansible callback plugin, so it records every run (task/host/result), including --check --diff drift runs from playbooks/sync.yml.
Postgres view collapsing ARA's run-history into current-state-per-(task, host) - latest changed/ok per backfill per host. That view is the drift matrix.
NocoDB → that same Postgres as an external base, exposing the view as a grid (backfill × host, color by status). NocoDB's external-DB connection means no ETL, no sync job - it reads ARA's live tables.

Tasks

Deploy ARA on kai-server, Postgres backend, wired as a stdout/notification callback in infrastructure/ansible (authored here; ansible role does the kai-server rollout).
Confirm playbooks/sync.yml --check --diff produces useful changed records in ARA (the drift signal).
Write the current-state-per-(task, host) Postgres view.
Deploy NocoDB on kai-server, connect it to ARA's Postgres as an external base, build the grid view over the matrix view.
Decide whether the grid is sufficient or whether n8n/Windmill glue is wanted to push back into Forgejo (open/close issues from the grid). Out of scope for first eval.

Scope / non-goals

ARA vs Semaphore UI is a separate decision (#326) - ARA records/reports, Semaphore orchestrates. Only ARA is needed here.
General Forgejo issue backlog stays in Forgejo; this is only for the host × backfill matrix, which is genuinely 2D and a poor fit for a flat issue list or single-axis kanban.
If NocoDB falls short, fall back candidates are Teable / Grist (#326).

Refs: #326

Split out of the self-hosting evaluation backlog (#326) as the first item to actually do, because it unblocks a concrete problem: organizing the scattered backfill / grandfather / rollout work that the ansible check surfaces. ARA + NocoDB together turn the ansible drift output into an Airtable-ish grid (backfill × host) without hand-maintaining a parallel backlog. ## Goal Stand up the drift-grid pipeline so the rollout/backfill matrix is a materialized view of the ansible check, not a hand-curated list. ## Pipeline (see #326 comment #10389 for the full reasoning) 1. **ARA backend → PostgreSQL** on kai-server. ARA is an ansible callback plugin, so it records every run (task/host/result), including `--check --diff` drift runs from `playbooks/sync.yml`. 2. **Postgres view** collapsing ARA's run-history into current-state-per-`(task, host)` - latest `changed`/`ok` per backfill per host. That view is the drift matrix. 3. **NocoDB → that same Postgres as an external base**, exposing the view as a grid (backfill × host, color by status). NocoDB's external-DB connection means no ETL, no sync job - it reads ARA's live tables. ## Tasks - [ ] Deploy ARA on kai-server, Postgres backend, wired as a stdout/notification callback in `infrastructure/ansible` (authored here; ansible role does the kai-server rollout). - [ ] Confirm `playbooks/sync.yml --check --diff` produces useful `changed` records in ARA (the drift signal). - [ ] Write the current-state-per-`(task, host)` Postgres view. - [ ] Deploy NocoDB on kai-server, connect it to ARA's Postgres as an external base, build the grid view over the matrix view. - [ ] Decide whether the grid is sufficient or whether n8n/Windmill glue is wanted to push back into Forgejo (open/close issues from the grid). Out of scope for first eval. ## Scope / non-goals - **ARA vs Semaphore UI** is a separate decision (#326) - ARA records/reports, Semaphore orchestrates. Only ARA is needed here. - General Forgejo issue backlog stays in Forgejo; this is only for the host × backfill matrix, which is genuinely 2D and a poor fit for a flat issue list or single-axis kanban. - If NocoDB falls short, fall back candidates are Teable / Grist (#326). Refs: #326

coilysiren added the

priority

label

2026-06-17 07:07:17 +00:00

coilysiren commented

2026-06-17 08:22:30 +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:22:30 +00:00

closed this issue
added the
burndown-2026-06
label

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-flight-deck/infrastructure#330

No description provided.

Rows
Columns