Problem
ORB's Cloud Readiness Phase B already tracks a dedicated admin API/CLI for provisioning a new customer deployment (the #4894-4902 family). AMS has no equivalent tracked anywhere. The fleet assets AMS shipped in Wave 4 — docker-compose.miner.yml, the k8s manifests, and the Terraform starter (#5177, #5181, #5183) — assume a single operator standing up their own infra; none of them address a central operator provisioning, listing, or tearing down many separate hosted customer instances. Without a design for this surface, any future hosted-AMS work has no admin-side entry point to build against.
Area
AMS / Fleet & ops management
Proposal
Design an admin-facing API/CLI surface for creating, listing, and tearing down a hosted AMS tenant instance. The design should be informed by — and explicitly reference — whichever storage-abstraction and control-plane pattern the AMS Cloud Readiness architecture spec settles on, so the provisioning surface is built on top of the agreed tenancy model rather than assuming its own.
Deliverables
- A design doc for the provisioning API/CLI surface: endpoint or CLI command shapes, the admin auth model, and the instance lifecycle states (e.g. provisioning, active, suspended, torn down)
- An explicit dependency note tying the design to the storage-abstraction and auth/identity design issues, including what changes if either lands differently than assumed
Resources
Boundaries
- Blocked on the storage-abstraction and auth/identity design issues landing first — this issue should not start until those settle the tenancy model it needs to build on.
- Design only: no implementation, no provisioning code, no live admin endpoints in this issue.
- Must not assume or hard-code a specific storage or auth mechanism ahead of the dependency issues — if either changes, this design needs to be revisited, not silently reconciled.
- This is architecture for a multi-tenant admin surface, not a routine feature addition — treat any ambiguity in the lifecycle-state model as blocking for follow-on implementation issues, not something to resolve informally in code later.
Problem
ORB's Cloud Readiness Phase B already tracks a dedicated admin API/CLI for provisioning a new customer deployment (the #4894-4902 family). AMS has no equivalent tracked anywhere. The fleet assets AMS shipped in Wave 4 —
docker-compose.miner.yml, the k8s manifests, and the Terraform starter (#5177, #5181, #5183) — assume a single operator standing up their own infra; none of them address a central operator provisioning, listing, or tearing down many separate hosted customer instances. Without a design for this surface, any future hosted-AMS work has no admin-side entry point to build against.Area
AMS / Fleet & ops management
Proposal
Design an admin-facing API/CLI surface for creating, listing, and tearing down a hosted AMS tenant instance. The design should be informed by — and explicitly reference — whichever storage-abstraction and control-plane pattern the AMS Cloud Readiness architecture spec settles on, so the provisioning surface is built on top of the agreed tenancy model rather than assuming its own.
Deliverables
Resources
docker-compose.miner.ymlfor AMS fleet mode with named services and restart policy #5177, Add example Kubernetes manifests (Deployment + Secret) for AMS fleet-mode as a small-cluster alternative to docker-compose #5181, Add a Terraform starter module for provisioning a dedicated fleet-mode AMS host #5183 (single-operator fleet mode, useful for contrast on what does not need a tenant concept yet)Boundaries