Executive summary
This case study tracks an in-progress lab expansion and design effort. It records present knowledge boundaries alongside the target architecture so planned components are never presented as installed inventory.
Owned hardware
No owned hardware inventory is publicly confirmed.
Currently deployed components
No currently deployed component set is publicly confirmed.
In-progress components
Lab expansion, architecture design, validation criteria, and operational runbook development are in progress.
Planned components
PXE provisioning, BMC/IPMI/Redfish workflows, Kubernetes foundations, Prometheus, and Grafana remain target capabilities until deployment evidence is confirmed.
Learning objectives
- Develop repeatable Linux provisioning and recovery workflows.
- Practice safe out-of-band management patterns.
- Build Kubernetes foundations after provisioning is validated.
- Define observable operations through telemetry and runbooks.
Problem
Develop a safe, repeatable lab environment for learning and validating bare-metal provisioning, out-of-band management, cluster foundations, and infrastructure observability.
Constraints
- Owned hardware inventory is not yet confirmed for public use.
- No currently deployed component set is publicly confirmed.
- Network, credential, access, and security-sensitive implementation details must not be published.
Architecture
Target architecture—not a statement of installed inventory—separates a management plane for PXE and BMC/IPMI/Redfish workflows from Linux compute hosts, with Kubernetes, Prometheus, and Grafana introduced in later validated phases.
Responsibilities
- Expand and refine the lab design around repeatable provisioning, recovery, and management workflows.
- Define validation evidence and operational runbooks before describing any component as deployed.
Implementation
Lab expansion and architecture design are in progress. No owned hardware inventory or currently deployed component set is publicly confirmed.
Operational considerations
- Design for rebuilds, health checks, telemetry, and documented failure recovery.
- Track target, in-progress, and confirmed-deployed components separately.
Security considerations
- Keep management interfaces isolated and credentials out of source control.
- Publish only sanitized diagrams and configuration examples after validating that they reveal no sensitive access detail.
Trade-offs
- Evidence-first reporting limits visible inventory detail but avoids presenting target architecture as an installed system.
Lessons learned
- Component status must be verified independently from architecture and learning plans.
Next iteration
- Confirm which owned hardware facts, if any, are appropriate for public use.
- Validate the smallest safe provisioning workflow before expanding the target architecture.