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

Arch bump: package the full o2r system as a Helm chart #25

New issue
Closed
opened 2026-06-02 02:52:24 +00:00 by coilysiren · 2 comments
coilysiren commented 2026-06-02 02:52:24 +00:00
Owner
Copy link

Arch bump

Package the full o2r system as a Helm chart so it runs as a real, always-on Kubernetes service rather than make-target demos. Scope: core relay, the Agent Channel layer (Postgres-backed), and the backend extension(s), deployable as one chart with values for peer registry, OTLP endpoint, and channel DB.

Why now

This is the major proto/arch change and it gates external outreach. o2r should be deployable and continuously running (ideally fronting real sessions) before pointing peers at it. It also unblocks standing up more real test peers across machines (a Beelink SER8 in particular) as A2A nodes that talk through a deployed relay instead of localhost.

Acceptance (rough)

  • chart/ with the relay + channels + at least one backend extension, templated values.
  • Runs on the homelab k8s, reachable as a stable service.
  • Real multi-host A2A sessions flow through the deployed relay and land as traces.

Sequencing peer: the existing o2r backlog (baseline chores + #1/#3/#14/#16) burns down around this.

## Arch bump Package the full o2r system as a Helm chart so it runs as a real, always-on Kubernetes service rather than `make`-target demos. Scope: core relay, the Agent Channel layer (Postgres-backed), and the backend extension(s), deployable as one chart with values for peer registry, OTLP endpoint, and channel DB. ## Why now This is the major proto/arch change and it **gates external outreach.** o2r should be deployable and continuously running (ideally fronting real sessions) before pointing peers at it. It also unblocks standing up more real test peers across machines (a Beelink SER8 in particular) as A2A nodes that talk through a deployed relay instead of localhost. ## Acceptance (rough) - `chart/` with the relay + channels + at least one backend extension, templated values. - Runs on the homelab k8s, reachable as a stable service. - Real multi-host A2A sessions flow through the deployed relay and land as traces. Sequencing peer: the existing o2r backlog (baseline chores + #1/#3/#14/#16) burns down around this.
coilysiren commented 2026-06-02 03:13:14 +00:00
Author
Owner
Copy link

Design head-start (2026-06-01)

Full design brief for a from-scratch session lives in the vault at Notes/o2r-helm-chart-handoff.md. Key points for anyone picking this up:

Greenfield for deploy. No Dockerfile, no chart, no deploy docs today. Step zero is a container image, then the chart.

Deployable surface to chart:

  • core relay (otel-a2a-relay-core): env OTEL_A2A_RELAY_{HOST,PORT,PEERS,STAR_ENFORCE}, OTEL_EXPORTER_OTLP_ENDPOINT, port 8080.
  • channels (otel-a2a-relay-channels): Postgres-backed FastAPI router, needs a DB.
  • backend extensions (arize-phoenix, tempo-grafana): dev/validation harnesses today, open whether any ship in-cluster.

Precedent to model: coilyco-flight-deck/lunch-money-k8s already has the full chart shape (chart/ with Chart.yaml, values.yaml, values.schema.json, deployment/service/ingress/configmap/secret/serviceaccount/hpa/pdb/networkpolicy templates, tests/test-connection), a Dockerfile, docs/deploy.md, and coily docker/helm-lint/helm-template verbs. Reuse wholesale.

Open design questions: one chart (relay+channels+Postgres) vs relay-only + external DB; bundle Postgres vs require existing; single image vs two; which backend (if any) in-cluster vs backend-agnostic OTLP; how cross-host peers (SER8) register/reach the relay over the tailnet; SSM-to-cluster secret delivery.

Conventions: image at docker.io/coilysiren/otel-a2a-relay; SSM-canonical secrets with existingSecret support; route dev verbs through coily and add chart verbs to .coily/coily.yaml first.

## Design head-start (2026-06-01) Full design brief for a from-scratch session lives in the vault at `Notes/o2r-helm-chart-handoff.md`. Key points for anyone picking this up: **Greenfield for deploy.** No Dockerfile, no chart, no deploy docs today. Step zero is a container image, then the chart. **Deployable surface to chart:** - core relay (`otel-a2a-relay-core`): env `OTEL_A2A_RELAY_{HOST,PORT,PEERS,STAR_ENFORCE}`, `OTEL_EXPORTER_OTLP_ENDPOINT`, port 8080. - channels (`otel-a2a-relay-channels`): Postgres-backed FastAPI router, needs a DB. - backend extensions (arize-phoenix, tempo-grafana): dev/validation harnesses today, open whether any ship in-cluster. **Precedent to model:** `coilyco-flight-deck/lunch-money-k8s` already has the full chart shape (`chart/` with Chart.yaml, values.yaml, values.schema.json, deployment/service/ingress/configmap/secret/serviceaccount/hpa/pdb/networkpolicy templates, tests/test-connection), a `Dockerfile`, `docs/deploy.md`, and coily `docker`/`helm-lint`/`helm-template` verbs. Reuse wholesale. **Open design questions:** one chart (relay+channels+Postgres) vs relay-only + external DB; bundle Postgres vs require existing; single image vs two; which backend (if any) in-cluster vs backend-agnostic OTLP; how cross-host peers (SER8) register/reach the relay over the tailnet; SSM-to-cluster secret delivery. **Conventions:** image at `docker.io/coilysiren/otel-a2a-relay`; SSM-canonical secrets with `existingSecret` support; route dev verbs through coily and add chart verbs to `.coily/coily.yaml` first.
coilysiren commented 2026-06-02 09:29:10 +00:00
Author
Owner
Copy link

Closing. The Helm-chart / deployable-service work split out into the otel-a2a-relay-deploy repo; fleet onboarding for it is tracked in #41 (migrated here from coilysiren/inbox).

Closing. The Helm-chart / deployable-service work split out into the `otel-a2a-relay-deploy` repo; fleet onboarding for it is tracked in #41 (migrated here from coilysiren/inbox).
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#25
No description provided.