Add docs/manager/backend-design.md — companion to ui-architecture.md
covering the backend that replaces the in-memory mock: package
layout, bbolt schema, REST surface derived from the UI, unified
operation orchestration pipeline, security model, SSH layer,
and on-demand refresh.
Lays out the fork strategy for the MinIO Go ecosystem. bm aims for
full mc CLI parity, so we fork wholesale rather than selectively
port. One coordinated pass forks Tier 1 (mc, madmin-go, minio-go,
pkg, cli) and Tier 2 (selfupdate, colorjson, kms-go) under
buckit-io/* — no upstream rebase obligation thereafter. CLI uses
the forked urfave/cli framework; HTTP backend uses the forked
madmin-go directly. Tier 3 specialised libraries stay as upstream
deps. Includes an alias bridge so forked mc commands resolve
cluster names from the bm store.
ui-architecture.md updated to match the simplified History page:
single source (UI-initiated mutable actions), structured row shape
(opKind/opLabel/clusterId/clusterName/hostScope/result), status
filter chips, no CLI source column.
phase1-implementation.md picks up TODOs from prior design rounds:
M8 cutover writes a systemd drop-in to run buckit as MinIO's
user/group; rollback-to-MinIO becomes a cluster Action visible when
migratedFrom is set.
- request-flow.md § 10.1: OS-level environment file as the layer that
feeds the process before .minio.sys is reachable. Covers the three
conventional paths (/etc/default/minio, /etc/minio/config.env,
/etc/sysconfig/minio), what lives there (root creds, MINIO_VOLUMES,
KMS bootstrap), and why those can't move into config.json.
- phase1-implementation.md: TODOs for M5 preflight (stale
.minio.sys/format.json detection, hostname pattern + drive
uniformity), drive preparation wizard deferred to M6.5 with full
safety requirements, and auto-save of bm alias to ~/.bm/config.json
(separate from mc's ~/.mc) on successful deploy/import. Data-key
bootstrap section corrects the path from /etc/bm/data.key to
~/.config/bm/data.key for personal-tool framing.
Adds four documents that form the Buckit Manager design corpus
alongside the existing README.md and phase1-web-ui.md:
- phase1-implementation.md: Phase 1 milestone plan (M0-M9), repo
layout, locked stack decisions, and a Progress section that tracks
what's landed in github.com/buckit-io/bm so work can resume cleanly
in a new session.
- ui-architecture.md: data flow (admin API + per-node connectivity
probes + SSH facts), the on-demand fetch pipeline with failure
isolation, REST contract sketch, per-page details for Clusters
list, Cluster detail, History, and Manager Settings, and the
proposed HostInfo extension to madmin.ServerProperties to surface
OS / CPU / Memory / Network in /admin/info.
- metrics.md: spec for the per-cluster Metrics tab (Info, Usage,
Traffic, Resources) — referenced by ui-architecture.md as the
source-of-truth for the existing /admin/info shape.
- authentication.md: notes on Console + mc CLI auth flows.
Introduces docs/manager/ with two design documents:
- README.md: high-level architecture for bm, a single-binary
operational control plane that ships as both a direct CLI and a
long-running `bm server` exposing an HTTP API and embedded web UI.
Covers the product model, distribution and packaging strategy,
agentless SSH cluster management, and a phased delivery plan
(Phase 1 manager foundation, Phase 2 CLI, Phases 3-4 progressive
mc replacement). Implementation-level subsystems, task model,
storage, and repository layout are kept in an appendix so the
high-level design reads cleanly.
- phase1-web-ui.md: wireframe-level web UI design for the first
release, scoped to the two operator journeys that only bm can
serve — deploying a new Buckit cluster on fresh hosts, and
migrating an existing MinIO deployment in place via binary swap.
Includes screen catalog, supporting operational surfaces, an
out-of-scope list that defers to the per-cluster Buckit console
for data-plane operations, and appendices covering the MinIO
compatibility surface and the package install path.
abuckit