8.4. DVM Bootstrap Plans
Implementation plans for the launcher-less bootstrap method of instantiating a persistent DVM.
- 8.4.1. DVM Bootstrap: Specification
- 8.4.2. DVM Bootstrap Implementation Plan
- 8.4.2.1. Approach
- 8.4.2.2. Step 1 — Factor the config parser into a shared utility
- 8.4.2.3. Step 2 — Compute identity and elect the controller
- 8.4.2.4. Step 3 — Publish identity through the existing MCA plumbing
- 8.4.2.5. Step 4 — Synthesize the controller contact URI
- 8.4.2.6. Step 5 — Apply the address family, listening port, and inter-node networks
- 8.4.2.7. Step 6 — Wire the
KeepFQDNHostnameskey - 8.4.2.8. Step 7 — Startup retry with capped exponential backoff
- 8.4.2.9. Step 7b — Radix wireup and ancestor healing
- 8.4.2.10. Step 8 —
prted.cbranch andprtebootstrap removal - 8.4.2.11. Step 9 — Controller-side node pool (
ras/bootstrap) - 8.4.2.12. Step 10 — Apply the operational and logging keys
- 8.4.2.13. Step 11 — Update the example config file and the configurator tool
- 8.4.2.14. Summary of files changed
- 8.4.2.15. Open risks
- 8.4.2.16. Testing
- 8.4.3. Rewiring a Returned Daemon: the “Unheal” Path
- 8.4.3.1. Problem statement
- 8.4.3.2. Scope and non-goals
- 8.4.3.3. Design principle: revival is the inverse of repair, not a special case of it
- 8.4.3.4. Separating “absent” from “dead”
- 8.4.3.5. The trigger: a returned daemon announces itself to the HNP
- 8.4.3.6.
prte_rml_revive_routing_tree— the recompute and its deltas - 8.4.3.7. Recovery-status and component impact
- 8.4.3.8. Bringing the returned daemon up to date
- 8.4.3.9. Concurrency and correctness concerns
- 8.4.3.10. Staged implementation plan
- 8.4.3.11. Testing
- 8.4.3.12. Resolved decisions
- 8.4.3.13. Open questions