03 · Core Infrastructure & Private Cloud
Milestones of the roadmap items in this theme
As of 2026-10-22 · today
Gantt
Milestones
| # | Milestone | Start | Target | Status | Waits for | Team | Epic | Derived |
|---|---|---|---|---|---|---|---|---|
| 08 · Enterprise-Grade Harvester HCI | ||||||||
| 8.1 | Fabric L3 design approved — server ↔ ToR routed, BGP to ToR | 2026-07-06 | 2026-08-14 | done | — | SRE | — | — |
| 8.2 | First rack group on L3 fabric — one rack group cut to BGP peering | 2027-01-01 | 2027-02-12 | planned | 8.1 | SRE | — | — |
| 8.3 | All server racks on L3 fabric | — | 2027-05-21 | planned | 8.2 | SRE | — | waiting 8.2 |
| 8.4 | Harvester ready to take production traffic | — | 2027-04-09 | planned | 8.2 | SRE | — | waiting 8.2 |
| 09 · KVM to Harvester Migration | ||||||||
| 9.1 | Harvester fixed as the default destination for rebuilds | — | 2027-04-23 | planned | 8.4 | SRE | — | waiting 8.4 |
| 9.2 | VM workloads rebuilt on Harvester and cut over | — | 2027-10-08 | planned | 2.3, 4.2, 9.1 | SRE | — | waiting 2.3, 4.2, 9.1 |
| 9.3 | Last libvirt host powered off | — | 2028-01-28 | planned | 9.2 | SRE | — | waiting 9.2 |
| 9.4 | Retired KVM hosts reinstalled as Harvester nodes | — | 2028-04-07 | planned | 5.4, 9.3 | SRE | — | waiting 5.4, 9.3 |
| 10 · DNS Architecture Refactoring | ||||||||
| 10.1 | New DNS accepted, and the clients still on the old resolver identified | 2026-08-10 | 2026-10-30 | in progress | — | SRE | — | — |
| 10.2 | Zone records under Terraform | — | 2027-02-12 | planned | 4.1 | SRE | — | waiting 4.1 |
| 10.3 | Clients cut over, old resolver retired | — | 2027-07-16 | planned | 2.3, 10.1 | SRE | — | waiting 2.3, 10.1 |
| 10.4 | Taichung Site B decommissioned | — | 2028-01-14 | planned | 10.3 | SRE | — | waiting 10.3 |
| 11 · Kubernetes cluster migration to the L3 fabric | ||||||||
| 11.1 | L3-mode K8s cluster provisioned — MetalLB BGP mode | 2027-01-01 | 2027-02-19 | planned | 8.2 | SRE | — | waiting 8.2 |
| 11.2 | Services migrated in waves, dual-running | — | 2027-03-26 | planned | — | SRE · Platform Engineering | — | — |
| 11.3 | Cutover complete, legacy cluster retired | — | 2027-07-16 | planned | 8.3 | SRE · Platform Engineering | — | waiting 8.3 |
Details
8.1Fabric L3 design approved — server ↔ ToR routed, BGP to ToR2026-08-14done · 2/2
- L2/L3 boundary and BGP peering design noteowner · CharlesWhere the L2 domain ends, which prefixes each ToR advertises, and how servers peer.
- Review with the network teamowner · Charles
8.2First rack group on L3 fabric — one rack group cut to BGP peering2027-02-12planned · 1/3
- Rack group A ToR BGP configowner · Charles
- Cut servers of rack group A to routed uplinksowner · TBDOne rack at a time, maintenance window per rack; rollback is the L2 trunk config kept on the ToR.
- Validate ECMP and failoverowner · TBD
8.3All server racks on L3 fabric2027-05-21planned · 0/3
- Rack groups B–D cutover wavesowner · TBD
- Decommission L2 trunksowner · TBD
8.4Harvester ready to take production traffic2027-04-09planned · 0/4
- Longhorn for local root disks and external Rook/Ceph for durable data is already drawn; what is not yet fixed is the capacity and the failure domains behind it.
- Backup and restore rehearsed on a real VM, not merely configuredowner · TBDA restore nobody has run is a setting, not a capability — and item 09 hands this platform every workload that cannot be containerised.
- The test for "may take production traffic" written down and signed offowner · TBDItem 09 waits on this milestone, so what it means has to be a stated test — not a judgement made later, under pressure, by whoever is on the cutover call.
9.1Harvester fixed as the default destination for rebuilds2027-04-23planned · 0/4
- Destination rule recorded against item 02's rebuild order: Harvester, Kubernetes, or stays putowner · TBDItem 02 rebuilds services; it does not decide where they land. Without this rule its waves rebuild onto libvirt, and the same services move a second time.
- Workloads sorted three ways: Kubernetes, containerised on Harvester, or a plain VMowner · TBDNot two. An application can be containerised and still be unable to run on Kubernetes — sticky sessions, logs on local storage, state that assumes a replica is never replaced. Those go to 25.4 as containers on Harvester, not to item 26. Item 09 carries only the third group: what cannot be containerised at all.
- One non-containerisable workload proven on Harvester before the waves commitowner · TBDThe workloads item 09 carries are the awkward ones — stateful appliances and licensed software. Discovering mid-wave that one of them will not run there is the most expensive order to discover it in.
- Item 2.1's cutover and rollback criteria extended to cover the change of hypervisorowner · TBDRolling back a rebuild is one thing; rolling back onto a hypervisor that is being retired is another. 2.1 was agreed before the destination was fixed.
9.2VM workloads rebuilt on Harvester and cut over2027-10-08planned · 0/4
- Services rebuilt on Harvester through item 02's waves and templateowner · TBDThe rebuild work belongs to 2.3; what item 09 adds is that the destination is Harvester. No second inventory, no second set of waves.
- Harvester VMs declared through the Terraform provider, not the consoleowner · TBD4.2 wires the provider up; this is where rebuilds are required to use it, so a migrated VM is code from its first day rather than after a later sweep.
- Ansible inventory generated from Terraform state, not a second listowner · TBDThe same handoff 4.4 establishes. A migration is exactly when a hand-kept inventory drifts, because every host changes address at once.
- Each workload cut over and its libvirt original retired, not left warmowner · TBD2.3 already asks this of rebuilds; here it is also what makes 9.3 reachable — a host cannot be powered off while something on it is being kept warm.
9.3Last libvirt host powered off2028-01-28planned · 0/3
- Remaining libvirt hosts emptied in a stated orderowner · TBD
- Hosts powered off first, removed only after a stated quarantineowner · TBDThe rule 3.2 set for orphaned VMs, applied to hosts — so a wrong call about what was still in use stays recoverable.
- The last host off, and the date recordedowner · TBDThe item is finished only when there is no second hypervisor left to maintain. A residual host or two is how two platforms quietly become permanent.
9.4Retired KVM hosts reinstalled as Harvester nodes2028-04-07planned · 0/4
- Hosts reconciled against their Netbox record before reuseowner · TBD5.1 makes Netbox the hardware source of truth; a host coming back from retirement is exactly when its record has gone stale.
- Reinstalled through the iPXE pipeline, with nobody logging inowner · TBD5.4 proves that path on a newly racked server; a reused host is the same path with a disk that already has an OS on it.
- Joined to the Harvester cluster and carrying workloadowner · TBD
- The hardware-ops handoff recorded: who racks and cables, who provisionsowner · TBDOwnership follows the pipeline, not the machine — hardware operations hand over a racked host, and provisioning is the same automated path as for any other node.
10.1New DNS accepted, and the clients still on the old resolver identified2026-10-30in progress · 2/4
- Records checked site by site against the intended answersowner · Charles
- Inventory of the machines still pointing at the old resolverowner · TBDThe architecture is in place; the client population is not. Until this list exists, "most machines" is the only statement anyone can make about what is left.
- That list split into what the rebuild waves will carry and what needs sweepingowner · TBDThe split is what decides how much of item 10 is its own work rather than a side effect of item 02.
10.2Zone records under Terraform2027-02-12planned · 0/4
- The three private hosted zones imported into state, not recreatedowner · TBDThe rule 4.1 sets for cloud accounts, applied here — the code has to describe the zones that are answering today before it is allowed to change them.
- Public and private zones both under the pipeline; the console path closedowner · TBDDNS is the one place where a hand-made change stays invisible until something cannot be found. Leaving the console open makes the pipeline one option out of two.
- Unbound's forward-zone configuration owned by the Ansible standardowner · TBD4.4 makes a host reproducible from code alone. A resolver whose forwarding was hand-edited is a host nobody can rebuild — and rebuilding it is exactly what a DNS outage calls for.
- Every zone change produces a reviewable diff before it is appliedowner · TBD
10.3Clients cut over, old resolver retired2027-07-16planned · 0/4
- Rebuilt machines point at the new resolvers from birthowner · TBDMost of the cutover is a property of items 02 and 09 rather than work item 10 performs; this task is the check that it actually holds.
- The residue swept: DHCP option changed, static configurations listed and fixedowner · TBDA DHCP change carries the machines that renew. The ones that do not are a list — and by then it is short enough to name every entry.
- Old resolver silenced and watched before it is removedowner · TBDStopping the answers surfaces whoever is still asking, while putting it back is still one command. Deleting first turns that discovery into an outage.
- Old resolver retiredowner · TBD
10.4Taichung Site B decommissioned2028-01-14planned · 0/4
- Where the names that resolved to Zone B point instead, decided firstowner · TBDZone B answers the same FQDNs as A and C, with site-local records. Removing it without answering this is how a site retirement takes out services that were never in that site.
- Site B Unbound pair, Route 53 inbound endpoint and Zone B removedowner · TBD
- Recorded as a precondition of the Taichung IDC retirement, not a consequence of itowner · TBDThe retirement is 3.5, which waits on this milestone. The direction matters: Zone B goes before the site, not with it, because the names have to point somewhere else first.
11.1L3-mode K8s cluster provisioned — MetalLB BGP mode2027-02-19planned · 1/3
- Provision the RKE2 cluster on the L3 fabricowner · Charles
- MetalLB BGP mode peering with the ToR pairowner · TBD
- Paths A · B · C of the datapath doc must each be observed on the new cluster.
11.2Services migrated in waves, dual-running2027-03-26planned · 0/3
- Migration wave plan per namespaceowner · TBD
- Wave 1 services dual-runningowner · TBD
- Waves 2–3 services dual-runningowner · TBD
11.3Cutover complete, legacy cluster retired2027-07-16planned · 0/2
- Final wave cutoverowner · TBD
- Retire the legacy clusterowner · TBD
Back to the Platform Roadmap overview · the direction behind these milestones is the Platform Roadmap.