Omar Sobh
24ff3ec130
Build with clawstor cache / Cargo build (clawstor-cached) (pull_request) Successful in 15s
README.md was still describing the pre-distributed ZFS-only
architecture (activate/deactivate cargo target dirs, SSH-based
tank→architect sync). Nothing about the distributed content-
addressed store, chunk-level dedup, QUIC/mTLS, snapshots, tags,
refs, FUSE mount, ref-tracking, Tailscale identity, or the
systemd timer set — i.e. everything shipped in Phases 1-8.
Full rewrite:
* What you get: 6 feature sections spanning storage/distribution,
fingerprint-keyed cargo cache, human primitives, operations,
roaming, reliability.
* One-paragraph architecture + link to ARCHITECTURE-v2.md.
* Fleet layout table (tank/architect/morpheus current state).
* Install: prereqs (Linux + macOS macFUSE), build, first-time CA
bootstrap, config template with tailnet bind, systemd install
recipe.
* Daily usage: claw-cargo build (env-driven for CI), pins,
snapshots, integrity+repair, fleet-status.sh, FUSE mount layout.
* CLI reference table (28 commands across claw-store + claw-cargo
+ claw-fuse).
* Prometheus metrics list.
* Ongoing operations: 4 timers table with sequencing rationale.
* Testing: 389 tests, known pre-existing macOS failure.
* Design-docs pointer list.
* Contributing + license note.
Also:
* ARCHITECTURE-v2.md phase plan table: replaced weeks-estimates
with ship-state (all ✅ shipped, dated).
* docs/runner-integration.md: added ref-tracking env-var section
so CI wiring populates the nightly sweep.
* dashboard/README.md: replaced the Vite template boilerplate
with actual dashboard context + note that it predates the
current architecture.
43 lines
1.3 KiB
Markdown
43 lines
1.3 KiB
Markdown
# clawstor dashboard
|
|
|
|
React + Vite frontend for the (legacy) `claw-store serve` HTTP API.
|
|
Displays node status, hot-tier usage, ZFS snapshots, and the sync
|
|
queue for the original ZFS-backed deployment.
|
|
|
|
**Note:** the primary observability path in the current distributed
|
|
architecture is Prometheus (`/metrics` on each node's `prom_bind`
|
|
port, default `:7703`) + `deploy/scripts/fleet-status.sh`. This
|
|
dashboard predates that and is not maintained as the operator's
|
|
main pane of glass. Kept in-tree because the underlying HTTP
|
|
endpoints on `claw-store serve` still function.
|
|
|
|
## Build
|
|
|
|
```bash
|
|
cd dashboard
|
|
npm install
|
|
npm run build
|
|
# → dist/ ready to serve from claw-store serve --static-dir <path>
|
|
```
|
|
|
|
## Dev
|
|
|
|
```bash
|
|
npm run dev
|
|
# Vite dev server + HMR against a running `claw-store serve` on :3030.
|
|
```
|
|
|
|
## What it shows
|
|
|
|
- `/api/status` — node role, uptime, hot usage, ZFS pool.
|
|
- `/api/projects` — active + branch + size per project.
|
|
- `/api/snapshots` — ZFS snapshot list.
|
|
- `/api/hot` — hot-tier entries.
|
|
- `/api/sync-queue` — pending retries.
|
|
- `/api/events` — SSE stream, updates every 5 s.
|
|
|
|
See the top-level [README](../README.md) for the current
|
|
architecture, which centers on the distributed content-addressed
|
|
blob store rather than the ZFS project mirror model this dashboard
|
|
was originally built for.
|