Phase 13 — Capstone: A Rack Management Platform

Difficulty: ⭐⭐⭐⭐⭐ | Estimated Time: 2 weeks Roles supported: Senior/Staff Rack Management SWE Hardware needed: none — the mini-platform composes the prior phases' simulators/emulators

Why This Phase Exists

Every prior phase built one capability; the capstone proves you can compose them into a coherent system — the actual job. You will build a mini rack-management platform that integrates: inventory (Phase 01), the Redfish/IPMI/SNMP driver abstraction (Phase 03), the provisioning state machine (Phase 05), the reconcile loop (Phase 06), telemetry/exporter (Phase 07), firmware orchestration (Phase 08), and secure multi-tenant configuration (Phase 09) — operated through a CLI (Phase 02), tested (Phase 11), and shipped with the Staff artifacts (Phase 12): a design doc, a runbook, and a retrospective.

This is what you show in an interview ("here's a rack-management platform I built end to end") and what proves you can do — and exceed — the JD on day one.

What You Build

A mini rack manager that takes a rack from discovered → ready → operated → maintained, as one program with clear seams:

                +------------------ Control plane ------------------+
   rackctl ---> | Inventory (P01) + reconcile loop (P06)            |
   (P02 CLI)    | Provisioning state machine (P05)                  |
                | Firmware orchestrator (P08)                       |
                | Telemetry/exporter (P07) + alerts                 |
                | Tenancy/secure config (P09)                       |
                +---------------------------------------------------+
                        | DeviceDriver abstraction (P03)
                +-------+--------+--------+
                | Redfish | IPMI | SNMP   |  (emulators/sims from P03/P04)
                +----------------+--------+

Deliverables:

  1. The integrated platform (capstone-mini-rack-manager/) — runnable, tested, composing the prior labs' patterns.
  2. A design doc — architecture, the seams, the key ADRs (Phase 12), the data model, failure handling, and what changes at fleet scale.
  3. A runbook (Phase 12) for a real operation (commission a rack / firmware rollout / node RMA).
  4. A release cycle — ship it through the Phase 11 pipeline (tests + canary) and write a retrospective (what worked, what you'd change, the RCA-style learnings).

The Build (suggested sequence)

  1. Model + reconcile: the inventory graph (Phase 01) + a reconcile loop (Phase 06) that drives each node toward READY at the firmware baseline.
  2. Drivers: the DeviceDriver abstraction (Phase 03) with a fake/emulated backend so it runs without hardware; one model above.
  3. Provision: the resumable state machine (Phase 05) with the validation gate (EBOM reconciliation — Phase 12) and attestation (Phase 09).
  4. Operate: the exporter (Phase 07) exposing fleet metrics + alerts; firmware orchestration (Phase 08) with A/B + rollback; tenancy/secure config (Phase 09).
  5. Interface: drive it all through the rackctl CLI (Phase 02), structured-logged and tested (Phase 11).
  6. Ship: design doc + runbook + canary release + retrospective (Phases 11–12).

Deliverables Checklist

  • The platform runs end to end: discover → provision → ready → operate → maintain, no hardware
  • One inventory model and one DeviceDriver abstraction underpin everything (no protocol leaks)
  • The reconcile loop converges nodes to baseline and corrects drift (idempotent, resumable)
  • Provisioning has a validation gate that quarantines bad nodes (EBOM + attestation)
  • Telemetry is exposed (Prometheus format) with alerts; firmware updates are A/B + rollback
  • Multi-tenant isolation invariants hold (no cross-tenant, no tenant→management)
  • It's operated via the CLI, structured-logged, and has a test suite (pyramid)
  • A design doc, a runbook, and a retrospective accompany it (Staff artifacts)

Interview Relevance

  • "Walk me through a rack-management system you've built." (this — end to end)
  • "Where are the seams, and why?" (driver abstraction, the testability seam)
  • "How does it handle a node that fails provisioning / a flaky BMC / a bad firmware?"
  • "What changes when this manages 10,000 nodes instead of one rack?" (→ system-design/)
  • "Show me the design doc and an ADR." (Phase 12)
  • This capstone is the portfolio that backs every other answer in the loop.