coilyco-flight-deck/otel-a2a-relay
Archived
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

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

New issue
Closed
opened 2026-06-02 23:11:43 +00:00 by coilysiren · 3 comments
coilysiren commented 2026-06-02 23:11:43 +00:00
Owner
Copy link

Part of #45 (per-layer isolated-unit packaging).

Layer: channels (otel-a2a-relay-channels v0.1.0) - the Agent Channel coordination layer: a FastAPI router (make_router(...)) + Postgres schema + Pydantic models. Postgres-backed.

Caveat unique to this layer: today it ships as a mountable library with no entrypoint - the router is built with caller-supplied pool_provider / auth_dependency and mounted into a host app. To package it as an isolated unit it needs a thin runnable app first.

Runnable app shim (prereq)

  • Add a minimal FastAPI app (__main__ / o2r-channels script) that builds the pool from env (DATABASE_URL / discrete PG vars), runs SCHEMA on startup, mounts make_router, and exposes a bearer auth_dependency.

Docker

  • Dockerfile running that app (uvicorn). Image ref 192.168.0.194:30500/otel-a2a-relay-channels:<git-sha>.

Helm

  • channels/chart/: the channels app Deployment + Service.
  • Postgres dependency: either a subchart/StatefulSet or values pointing at an external DB (channelDb values per #25's original scope). Templated OTLP endpoint, base_url, auth.

Acceptance

  • App shim runs locally against a Postgres and serves /agent-channel/....
  • Image builds + pushes; chart installs with a reachable Postgres and emits channel-event spans.
Part of #45 (per-layer isolated-unit packaging). **Layer:** `channels` (`otel-a2a-relay-channels` v0.1.0) - the Agent Channel coordination layer: a FastAPI router (`make_router(...)`) + Postgres schema + Pydantic models. Postgres-backed. **Caveat unique to this layer:** today it ships as a *mountable library* with **no entrypoint** - the router is built with caller-supplied `pool_provider` / `auth_dependency` and mounted into a host app. To package it as an isolated unit it needs a thin runnable app first. ### Runnable app shim (prereq) - Add a minimal FastAPI app (`__main__` / `o2r-channels` script) that builds the pool from env (`DATABASE_URL` / discrete PG vars), runs `SCHEMA` on startup, mounts `make_router`, and exposes a bearer `auth_dependency`. ### Docker - Dockerfile running that app (uvicorn). Image ref `192.168.0.194:30500/otel-a2a-relay-channels:<git-sha>`. ### Helm - `channels/chart/`: the channels app Deployment + Service. - Postgres dependency: either a subchart/StatefulSet or values pointing at an external DB (`channelDb` values per #25's original scope). Templated OTLP endpoint, base_url, auth. ### Acceptance - App shim runs locally against a Postgres and serves `/agent-channel/...`. - Image builds + pushes; chart installs with a reachable Postgres and emits channel-event spans.
coilysiren commented 2026-06-02 23:30:20 +00:00
Author
Owner
Copy link

Constraint: the packaged channels service is tailnet-only

The new channels deployment must be tailnet-only, matching the current backend's posture (today's channels API is reached via the http://api tailnet sidecar, and its Postgres backend-db is tailnet-reachable - no public surface). Carry that forward:

  • No public ingress. Expose the channels Service only on the tailnet - a Tailscale sidecar / tailscale serve (or the existing api ingress pattern), not a public LoadBalancer/Ingress.
  • Postgres stays in-cluster / tailnet-only; never a public endpoint.
  • o2r clients reach it via a tailnet base_url (the O2R_BASE_URL / config base_url repoint at #52 cutover points at a tailnet address, not a public one).
  • Chart values should make the tailnet-only exposure the default, with no public-ingress path templated in.

This is a hard requirement (Kai, 2026-06-02), not a default to be overridden.

### Constraint: the packaged channels service is tailnet-only The new channels deployment must be **tailnet-only**, matching the current backend's posture (today's channels API is reached via the `http://api` tailnet sidecar, and its Postgres `backend-db` is tailnet-reachable - no public surface). Carry that forward: - **No public ingress.** Expose the channels Service only on the tailnet - a Tailscale sidecar / `tailscale serve` (or the existing `api` ingress pattern), not a public LoadBalancer/Ingress. - Postgres stays in-cluster / tailnet-only; never a public endpoint. - `o2r` clients reach it via a tailnet `base_url` (the `O2R_BASE_URL` / config `base_url` repoint at #52 cutover points at a tailnet address, not a public one). - Chart values should make the tailnet-only exposure the default, with no public-ingress path templated in. This is a hard requirement (Kai, 2026-06-02), not a default to be overridden.
coilysiren commented 2026-06-02 23:33:55 +00:00
Author
Owner
Copy link

Refinement (Kai, 2026-06-02): secure-by-default + exposure-as-plugin

Supersedes the earlier "tailnet-only, hardwired" note. Same intent (tailnet is the reachability path), cleaner architecture:

1. Postgres is not accessible by default.

  • No exposed Service for Postgres - ClusterIP-internal at most, ideally no Service beyond what the channels app needs. Never a NodePort/LoadBalancer, never tailnet-exposed, never public.
  • A NetworkPolicy restricts ingress to the channels app pod only.
  • Credentials come from a Secret; no default/baked passwords. The DSN the app uses is the only path in.
  • The chart must be installable with Postgres fully locked down as the default - opening any access is an explicit operator opt-in.

2. Tailscale is a loosely-coupled plugin, not core.

  • The core channels chart is exposure-agnostic: it stands up the app + (locked-down) Postgres and a ClusterIP Service, and runs to completion with no Tailscale present.
  • Tailnet exposure ships as a separate, optional plugin/subchart (Tailscale sidecar or operator Ingress), off by default (tailscale.enabled=false or a discrete add-on chart). Enabling it is what makes the service tailnet-reachable.
  • This keeps the deployment portable: the same core chart can sit behind a different exposure plugin later without edits.

3. Future "serious business" integrations - document only for now.

  • Productization surfaces (e.g. a Lunch Money MCP and other external/commercial integrations) are out of scope for this pass. Capture them as documented future extension points so the plugin seams account for them; do not build. Tracked separately (parked issue).

Framing: maximum professionalism - secure-by-default, pluggable exposure, documented extension seams.

### Refinement (Kai, 2026-06-02): secure-by-default + exposure-as-plugin Supersedes the earlier "tailnet-only, hardwired" note. Same intent (tailnet is the reachability path), cleaner architecture: **1. Postgres is not accessible by default.** - No exposed Service for Postgres - ClusterIP-internal at most, ideally no Service beyond what the channels app needs. Never a NodePort/LoadBalancer, never tailnet-exposed, never public. - A `NetworkPolicy` restricts ingress to the channels app pod only. - Credentials come from a Secret; no default/baked passwords. The DSN the app uses is the only path in. - The chart must be installable with Postgres fully locked down as the **default** - opening any access is an explicit operator opt-in. **2. Tailscale is a loosely-coupled plugin, not core.** - The core channels chart is **exposure-agnostic**: it stands up the app + (locked-down) Postgres and a ClusterIP Service, and runs to completion with **no Tailscale present**. - Tailnet exposure ships as a separate, optional plugin/subchart (Tailscale sidecar or operator `Ingress`), off by default (`tailscale.enabled=false` or a discrete add-on chart). Enabling it is what makes the service tailnet-reachable. - This keeps the deployment portable: the same core chart can sit behind a different exposure plugin later without edits. **3. Future "serious business" integrations - document only for now.** - Productization surfaces (e.g. a Lunch Money MCP and other external/commercial integrations) are out of scope for this pass. Capture them as documented future extension points so the plugin seams account for them; do not build. Tracked separately (parked issue). Framing: maximum professionalism - secure-by-default, pluggable exposure, documented extension seams.
coilysiren commented 2026-06-17 08:23:46 +00:00
Author
Owner
Copy link

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:46 +00:00
Commenting is not possible because the repository is archived.
No Branch/Tag specified
Branches Tags
main
chore/coilysiren-org-ref-update
dependabot/uv/uv-e1a0e186ab
No results found.
Labels
Clear labels   
burndown-2026-06
Backlog burndown June 2026

  
coherence-core
Core review set for the warded control plane coherence milestone. These issues form the release spine; adjacent milestone issues are stretch or supporting work.

  
consult
A human decision, design, or external action must happen first. Fail-closed default for unlabeled/low-confidence.

  
headless
Agent can take it from open issue to merged change with no human in the loop. The auto-burndown queue.

  
interactive
Agent does the work but pauses at a human checkpoint mid-flight (design choice, destructive step, human-only verification).

  
P0
now / blocking / urgent

  
P1
next / important

  
P2
backlog / will do

  
P3
someday / low

  
P4
icebox / frozen / reopen if it becomes real

No labels
burndown-2026-06
coherence-core
consult
headless
interactive
P0
P1
P2
P3
P4
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
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/otel-a2a-relay#47
No description provided.