Files
harmony/harmony_app/README.md
Jean-Gabriel Gill-Couture eea006535b refactor: drop harmony_app landfill
Scores own deploy. harmony_app is identity, images, context, and
HarmonyApp→Scores. Authoring DX lives in dx. Compose/chart/Application
model and the Helm render test are gone.
2026-09-08 22:10:34 -04:00

65 lines
3.0 KiB
Markdown

# harmony_app
Application delivery. A [`HarmonyApp`](src/app.rs) composes **Scores**; `ship` /
`deploy` / `status` / `logs` are glue that interpret them. This crate does **not**
orchestrate infrastructure — that is [`harmony`](../harmony).
## Architecture
| Crate | Job |
|---|---|
| **`harmony_cli`** | UI only. Parse argv, require `--context`, call verbs, render. Safe types and DX (digest-shaped flags, `--json`). No Scores, no image policy, no cluster mutation. |
| **`harmony_app`** | Application delivery: identity, image build/publish, context catalog, `HarmonyApp` → Scores, ship/deploy as interpret glue. Authoring DX in [`dx`](src/dx.rs) (one component, one file, one type). |
| **`harmony`** | Source of truth for infrastructure orchestration. Scores (desired state), Topologies (where), Interpret (how). Deploying Kubernetes resources, running containers, building the deployment model and applying it on a topology (k8s or otherwise). |
| **`harmony_config`** | Load, save, discover settings and secrets. Schema is Rust; state is a store. Default store is OpenBao (CNCF). |
Identity is one SSO (`https://sso.nationtech.io`). That identity is what may
read the tenant's config and environment in OpenBao, the OKD cluster, Harbor,
and later more.
**SSO is still WIP for Harbor and OKD.** Access secrets for those live in
OpenBao, which *is* SSO. Current flow:
1. Load one secret: `HARMONY_ZITADEL_KEY_JSON` (or `HARMONY_ZITADEL_KEY_PATH`).
2. Authenticate to OpenBao (JWT-bearer against Zitadel).
3. Load Harbor and kubeconfig from OpenBao.
4. Authenticate to Harbor and Kubernetes with those secrets.
Interactive humans use device-code OIDC to the same OpenBao instead of a
machine key. Same store, different first hop.
`--context` is required (or `HARMONY_CONTEXT`). There is no default.
`K8sAnywhereTopology` on `app_main` / `AppContext::topology()` is the
**control plane** (kube apply — including Fleet CRs). It is not a claim that
the workload runs on Kubernetes.
## Crate map
**UI:** `harmony_cli`, `harmony_tui`, `harmony_auth_cli`, `harmony_auth_ui`
**Application delivery:** `harmony_app`
**Orchestration:** `harmony`, `harmony-k8s`, `harmony-reconciler-contracts`,
`harmony_execution`, `k3d`, `fleet/*`
**Config & secrets:** `harmony_config`, `harmony_config_derive`, `harmony_secret`,
`harmony_secret_derive`
**Identity:** `harmony_zitadel_auth`, `harmony_zitadel_jwt`, `harmony_auth`
**Shared types:** `harmony_types`, `harmony_macros`
Infra-specific crates (OPNsense, NATS, agents, Brocade, …) live under `harmony`
modules or their own crates; they are Scores/topologies, not app delivery.
## Remaining leaks (honest)
- `status` / `logs` list Kubernetes Deployments/Pods via the control-plane
client. Operational verbs are allowed to read the cluster (ADR-026); they are
not yet Score-status.
- `harmony_cli::run` is a second frontend: a generic Score runner over Maestro.
Still UI. Not application delivery.
- `dx::Secret` is a stub. Secrets today are OpenBao-backed config structs, not
a `Secret<T>` field type.