You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor(stovepipe): collapse to a single Ping-only service (#271)
## Summary
### Why?
Stovepipe was scaffolded with the full two-service shape (gateway +
orchestrator) plus entities, storage extensions, and queue/topic wiring
copied from SubmitQueue. None of that is exercised yet — the only
working surface is the `Ping` health check. Carrying the unused
gateway/orchestrator split, entities, extensions, and pipeline plumbing
adds maintenance cost (mocks, schemas, compose stacks, build targets)
with no behavior behind it.
### What?
Reduce Stovepipe to a single Ping-only service and promote its packages
to the domain top level:
- Wire contract: replace `api/stovepipe/{gateway,orchestrator}/` with a
single `api/stovepipe/proto/stovepipe.proto` (service
`uber.submitqueue.stovepipe.Stovepipe`, `Ping` only) and regenerated
`api/stovepipe/protopb/`. The `change` import and `Ingest` RPC are
dropped.
- Domain: promote the controller to `stovepipe/controller/`
(`ServiceName: "stovepipe"`). Remove
`stovepipe/{gateway,orchestrator,entity,extension,core}/`.
- Example: collapse to one `example/stovepipe/server` +
`example/stovepipe/client` and a single-service `docker-compose.yml`
with no MySQL/queue dependency (default gRPC port `:8083`, `:8080` in
Docker).
- Integration test: `test/integration/stovepipe/` now exercises Ping
only (no MySQL/schema), context `svc-stovepipe`.
- Wiring: single `api_stovepipe` codegen target in `tool/proto`, one `#
gazelle:resolve` for `api/stovepipe/protopb`, and Makefile targets
consolidated to `build-stovepipe-linux` /
`local-stovepipe-start|stop|logs` / `run-client-stovepipe`.
- Docs: `stovepipe/README.md`, `example/README.md`, and
`doc/howto/TESTING.md` updated to the single-service layout.
Entities, extensions, and the orchestration pipeline can be reintroduced
incrementally as Stovepipe grows real behavior.
## Test Plan
- ✅ `make proto` && `make gazelle` && `make tidy` (no unexpected churn)
- ✅ `make build` (230 targets)
- ✅ `make test` (59 tests, incl.
`//stovepipe/controller:controller_test`)
- ✅ `make fmt`, `make lint-license`
- ✅ `bazel build //test/integration/stovepipe:stovepipe_test` and all
`//{api,example,}/stovepipe/...`
The `platform/` tree holds code reused across domains (infrastructure, shared entities, shared extension contracts). Each **domain** (`submitqueue/`, `stovepipe/`, …) keeps the same internal layout (`gateway/`, `orchestrator/`, `entity/`, `extension/`, `core/`); a domain's own `core/` (e.g. `submitqueue/core/`) holds infra shared only between that domain's services.
66
+
The `platform/` tree holds code reused across domains (infrastructure, shared entities, shared extension contracts). Each **domain** (`submitqueue/`, `stovepipe/`, …) grows into the same internal layout (`gateway/`, `orchestrator/`, `entity/`, `extension/`, `core/`); a domain's own `core/` (e.g. `submitqueue/core/`) holds infra shared only between that domain's services. A domain may start smaller — Stovepipe is currently a single Ping-only service with just `controller/` (and a service-segment-free `api/stovepipe/`), adding the other layers as it gains real behavior.
71
67
72
68
The `api/` tree holds **published** wire contracts — those depended on from outside the owning domain. RPC contracts live at `api/{domain}/{service}/` (`proto/` for `.proto` sources, `protopb/` for committed generated Go); a service package may hold multiple `.proto` files, all generating into the same `protopb/`. External message-queue contracts live at `api/{domain}/messagequeue/` (see Message Queue Contracts below). Internal queue contracts do **not** go here — they live under `{domain}/core/messagequeue/`.
@@ -62,7 +60,7 @@ build: ## Build all services and examples
62
60
@echo "Build complete!"
63
61
64
62
# Build Linux binaries required for Docker containers
65
-
build-all-linux: build-submitqueue-gateway-linux build-submitqueue-orchestrator-linux build-stovepipe-gateway-linux build-stovepipe-orchestrator-linux build-runway-orchestrator-linux ## Build all Linux binaries for Docker
63
+
build-all-linux: build-submitqueue-gateway-linux build-submitqueue-orchestrator-linux build-stovepipe-linux build-runway-orchestrator-linux ## Build all Linux binaries for Docker
66
64
@echo "All Linux binaries ready for Docker"
67
65
68
66
build-runway-orchestrator-linux: ## Build Runway orchestrator Linux binary for Docker
@@ -89,21 +87,13 @@ build-submitqueue-orchestrator-linux: ## Build Orchestrator Linux binary for Doc
Copy file name to clipboardExpand all lines: README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ Designed for large monorepos and fast-moving teams where concurrent changes can
10
10
11
11
## Repository layout
12
12
13
-
Cross-domain Go code (errors, metrics, consumer framework, HTTP helpers, shared entities, shared extension contracts) lives under [`platform/`](platform/README.md). Each product domain has its own tree (`submitqueue/`, `stovepipe/`, …) with `gateway/`, `orchestrator/`, `entity/`, `extension/`, and domain-local `core/`. See [CLAUDE.md](CLAUDE.md) for conventions and import paths.
13
+
Cross-domain Go code (errors, metrics, consumer framework, HTTP helpers, shared entities, shared extension contracts) lives under [`platform/`](platform/README.md). Each product domain has its own tree (`submitqueue/`, `stovepipe/`, …) and grows into `gateway/`, `orchestrator/`, `entity/`, `extension/`, and domain-local `core/` — though a domain may start smaller (Stovepipe is currently a single Ping-only service with just `controller/`). See [CLAUDE.md](CLAUDE.md) for conventions and import paths.
0 commit comments