o2r packaging: migrate deploy/services chart in-tree; strip coilyco-bridge/deploy to pure GitOps #51
Labels
No labels
burndown-2026-06
coherence-core
consult
headless
interactive
P0
P1
P2
P3
P4
No milestone
No project
No assignees
1 participant
Due date
No due date set.
Dependencies
No dependencies set.
Reference
coilyco-flight-deck/otel-a2a-relay#51
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Part of #45. Reframed (Kai, 2026-06-02):
otel-a2a-relay-deploywas already renamed/reframed intocoilyco-bridge/deploy, a general-purpose deploy monorepo that currently holds the o2r Dockerfile + Helm chart + manifests. The decision is to migrate the in-tree-able bits out and makedeploypure GitOps.Scope
deploy/services/otel-a2a-relay/Dockerfileanddeploy/services/otel-a2a-relay/chart/intootel-a2a-relayin-tree (relay chart ->core/chart/, Dockerfile ->core/). Preserve the existing chart templates (deployment, service, ingress, hpa, pdb, networkpolicy, secret, serviceaccount, values.schema.json, tests) - this is a move + adapt, not a rewrite.deploy: the ArgoCDApplication(s) and per-env values (deploy/services/otel-a2a-relay/deploy/values, tailscale-service as the exposure plugin's values), now pointing at the OCI-published chart instead of a local path.deploy/README.mdsays "service repo stays unaware of how it is deployed" - update to "charts live with code, deploy holds GitOps state + values."otel-a2a-relayREADME.md## Deployto the in-tree + OCI + ArgoCD model.Acceptance
deploy/services/*/; only ArgoCD apps + values.## Deployand deploy README both describe the in-tree-chart / OCI / ArgoCD model with no contradictions.o2r packaging: rewrite README Deploy + retire otel-a2a-relay-deployto o2r packaging: migrate deploy/services chart in-tree; strip coilyco-bridge/deploy to pure GitOpsBacklog 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.