Service Dependencies & Startup Order
Runtime and configuration dependencies across routing, secrets, UniFi control, DNS, storage, backups, and platform services, including committed boot order and degraded behavior.
Service dependencies separate what must exist for traffic to flow from what is needed only to configure, observe, or recover the system. OPNsense is the first routed service at each site; storage, secrets, naming, backup, and platform layers come up behind the local network boundary.
Only the Three Edge Services Have a Committed Numeric VM Order
Pulumi declares OPNsense order=1,up=90,down=180, OpenBao order=2,up=60,down=180, and Site A UOS order=3,up=0,down=180. DNS, PBS, monitoring, and platform services do not yet have committed numeric Proxmox startup values.
Dependency Layers
| Layer | Required foundation | Provides | Failure behavior |
|---|---|---|---|
| Physical and Layer 2 | Power, host NICs, switch links, VLAN profiles | Local Ethernet, trunks, access ports, RSTP paths | Same-switch or surviving-path traffic may continue; routed services are not implied |
| Site routing | Local E200, WAN/LAN NICs, OPNsense VM | Gateways, NAT, DHCP, inter-zone policy, WireGuard, DNS forwarding | Same-VLAN Layer 2 may continue; routed and internet traffic stops |
| Edge control | OPNsense first | OpenBao and UOS network reachability | OpenBao unseal and remote UniFi management need routing; forwarding does not require UOS |
| Naming | VLAN 30, local routing, Technitium DNS VMs | core.aorxi.io, reverse zones, client resolution | Replicas serve the last transferred copy when the primary or tunnel is unavailable |
| Durable data | Local disks, ZFS or Ceph, storage VLANs | VM data, service state, backup datastores | Failure stays site-local; no storage plane stretches across WireGuard |
| Backup and recovery | Local storage, PBS, VLAN 90 | Local backups and planned cross-site copies | Local jobs do not require WireGuard; replication pauses with the tunnel |
| Platforms | Routing, DNS, compute, and required storage | Kubernetes/OpenShift, ingress, monitoring, applications | Platform startup waits until its local network and storage prerequisites are stable |
No Cross-Site Quorum or Storage Dependency
Proxmox quorum, Corosync, Ceph, Layer 2, and OpenBao Raft remain site-local. WireGuard carries routed application flows only and cannot become a prerequisite for local cluster health.
Committed Edge Startup Order
| Order | System | Startup rule | Readiness gate |
|---|---|---|---|
| 0 | E200 host networking | Physical WAN, LAN trunk, management, and Proxmox bridges exist before guest startup | Local management and attached VLANs are present |
| 1 | sa-fw-01 / sb-fw-01 | up=90, down=180; its up window delays order 2 | Local gateways and required routed paths answer |
| 2 | sa-bao-01 / sb-bao-01 | up=60, down=180; its up window delays order 3 | bao status reports initialized and unsealed |
| 3 | sa-uos-01 | up=0, down=180 | UOS API responds and adopted devices are reachable |
| After network and storage | DNS, PBS, monitoring, core service VMs | Dependency order is architectural; numeric VM orders are not recorded | Local DNS resolves, datastores mount, and service health checks pass |
| After foundations | Kubernetes/OpenShift and application workloads | Start only after network and storage are stable | Control-plane, storage, ingress, and DNS checks pass |
OpenBao Boot State
Site A currently uses Shamir manual unseal after an OpenBao reboot. Once Site B exists, each OpenBao instance is designed to use the other site's transit engine over WireGuard.
Current and Target Unseal Paths Differ
Today, sa-bao-01 requires three of five Shamir keys after a reboot. The future cross-site transit design makes OPNsense-first startup mandatory because the tunnel becomes the unseal path. A simultaneous two-site cold start retains a documented manual seal-migration break-glass path.
Restarting OpenBao seals the server. Configuration changes that support reload use systemctl reload openbao; an intentional restart requires an unseal plan.
Proxmox up is a fixed delay after the current VM starts, not a readiness probe. The API and status checks remain mandatory after boot.
Runtime and Configuration Dependencies
| Consumer or capability | Runtime dependency | Configuration dependency | Degraded or fallback path |
|---|---|---|---|
| OPNsense packet forwarding | Its own running VM and stored configuration | OpenBao or encrypted vault credentials for future config pushes | Runtime traffic continues if OpenBao is sealed |
| Pulumi provisioning | Proxmox API and tier-0 bootstrap credentials | OpenBao is preferred for Proxmox credentials | Root .env.local remains the break-glass fallback |
| OPNsense and UniFi Ansible | Reachable target API | OpenBao AppRole and KV v2 are preferred | Encrypted vault-credentials.yml files remain the fallback |
| UniFi forwarding | Adopted switch/AP local configuration | UOS for adoption, telemetry, and changes | Existing switching and Wi-Fi forwarding continue while UOS is down |
| DNS resolution | One reachable local DNS replica | sa-dns-01 for authoritative writes and zone replication | Secondaries answer from the last transferred zone copy |
| Local PBS jobs | Local PBS and datastore | Local management plane | Jobs continue without WireGuard |
| Cross-site PBS copies | Both PBS endpoints, VLAN 90, WireGuard | Replication job configuration | Copies pause; local backup operation continues |
| Site B DNS updates | Site B resolver plus routed access to the primary | WireGuard reachability to sa-dns-01 | Existing Site B zone data remains readable; new changes wait |
Recovery Startup Sequence
- Restore physical links, local switching, Proxmox management, and the E200 network bridges.
- Start and validate OPNsense before any service that needs routed reachability.
- Start OpenBao, then complete the current Shamir unseal or future transit-unseal recovery.
- Start UOS and DNS; verify control access and local name resolution.
- Mount or validate ZFS/Ceph and bring PBS datastores online.
- Start monitoring, certificate, Kubernetes/OpenShift, and application services only after their network and storage gates pass.
Only the three edge services currently have committed Proxmox startup metadata. Disaster recovery objectives records the related recovery gaps, while blast radius & recovery shows what each dependency failure affects.
Full Two-Site System Map
Interactive estate-wide diagram of every named host, switch, edge VM, service workload, and logical platform across both sites, with IPs, networks, purpose, placement, and connections.
Security Trust Zones & Permitted Flows
Target default-deny policy for WAN, management, services, workloads, DMZ, monitoring, backup, trusted, IoT, guest, storage, and inter-site traffic.