Files
oikos/runbooks/lifecycle-migrate-node.md
dtoro f6b57cbe3a Oikos Week 2: Service Console v0, change ledger, node relations, runbooks
Adds the shared kernel modules (oikos/policy.py, oikos/relations.py,
oikos/ledger.py) that let every surface — CLI, MCP, context-card
generator — agree on risk classification and ontology graph walks
from one implementation.

homelab CLI: `service <name> explain|health|docs|log|actions|history`
(Service Console v0), `change preflight <service>`, `node <name>
relations`. Restart and client add/remove now append change-ledger
entries (ledger/*.jsonl, committed alongside the change they record).

mcp/server.py mirrors explain/preflight/get_relations/get_change_history
as MCP tools, card-first so agent orientation is one call instead of
several search_docs/get_page round-trips.

oikos/gen-topology.py now also emits a compact context card per host
and service (oikos/cards/*.md) — identity, blast radius, safe actions +
risk class, doc pointer, recent ledger history.

runbooks/*.md: service health check, config change + deploy, client
enrollment, incident investigation, and the five node lifecycle
transitions (provision/activate/migrate/deprecate/destroy), each with
machine-readable frontmatter (risk class, inputs, verification,
docs-update checklist). Wired into HERMES.md so agents load these
instead of rediscovering topology per-task.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-05 23:02:32 +02:00

1.9 KiB

name, risk_class, inputs, verification, docs_update_checklist, transition
name risk_class inputs verification docs_update_checklist transition
lifecycle-migrate-node config_mutation
node_name
source_host
target_host
homelab node <name> relations (re-check blast radius); homelab service <svc> health for every hosted service
doc_page_migration_note
inventory_host_and_lan_ip
active -> migrating -> active

Lifecycle: migrate a node

Modeled on the strong Phase 1+2 migration (plans/2026-06-03_110000-library-ssd-migration-to-ludo-mini.md). Requires (ontology): preflight + backup-verified before migrating; post-verify + Caddy backends checked + mounts checked + docs updated before returning to active.

  1. homelab change preflight <every service the node hosts> — capture current health as a baseline.
  2. Verify backups are current for anything with data at rest on the node (see backs-up-to edges once populated).
  3. Set state: migrating in inventory.yaml.
  4. Perform the migration (pct/qm move, or create-on-target + data-copy + destroy-source, per the specific case).
  5. Update inventory.yaml: new host:, lan_ip, mesh addresses for the node; update every services: entry whose backend pointed at it if the backend name itself changes (usually it doesn't — only the host:/lan_ip on the guest entry moves).
  6. Post-verify: re-run the Week-1 drift check by hand — confirm Caddy's backend IP for each affected service matches the new lan_ip (automatic in Week 3's drift detector), confirm mounts still resolve.
  7. homelab service <name> health for every service the node hosts.
  8. Set state: active. Add a migration note to the node's doc page (old host/IP → new, date, phase reference) — this repo's convention for every past migration (see containers/101-jellyfin.md, containers/129-house.md).

Regenerate: python3 mcp/build_host_files.py && python3 oikos/gen-topology.py.