Compute and networking
Infra
Network boot and application handoff
Infra provides network boot for physical machines on a trusted LAN. The controller maintains address and image declarations; Bootstrap verifies the image and prepares the runtime; the application takes over at its own /init. Image publication, execution handoff and readiness are checked separately so operators can identify the machine’s actual progress.
Replace a machine while retaining its business address Discover the replacement, inspect its lease and hardware, then declare its address and application image. Once the old lease has ended, the new machine can use that address. The application reads its durable data and establishes service recovery.
Give each machine a defined runtime
Infra targets x86-64 UEFI machines on a trusted, isolated IPv4 LAN. Its controller supplies network boot, image publication and current machine observations. Bootstrap is the initial operating environment; each application image carries its own entry point and execution dependencies.
Operators maintain two independent declarations: the static business address for a boot interface, and the image name it should select. DHCP, the service that leases network addresses, can discover a machine before either declaration exists. It then waits for an assignment; a hardware report is not required for discovery.
Prepare the network facts and a complete application
A deployment needs three inputs: boot-network configuration under the operator’s control, the mapping between machine interfaces and addresses, and a self-contained application image. The network input identifies the address pool, gateway and routes. The image contains /init and its actual execution dependencies; files incidentally present in the bootstrap system are not application dependencies.
The business address and boot content have separate declarations. A machine may be assigned an image name before that content is published. If either the binding or image is missing, it waits instead of selecting another application. Maintenance SSH has its own authorization; choosing an image does not grant remote administration rights.
Identify the network and machine
Use the actual DHCP lease to identify the boot interface and check the isolated network, address range and current allocations. Hardware reports provide context but are not required for discovery.
Submit the two declarations
Set the static business address and image name separately. If a conflicting lease remains valid, resolve that lease through its actual lifecycle.
Publish and observe the handoff
After uploading the complete image, observe the acquired address, selected content and the application’s own output. Each observation answers a different question.
Turn current declarations into complete images
After a static declaration is committed, the client obtains its actual address through DHCP renewal and rediscovery. An address held by another machine’s unexpired lease causes rejection without changing declarations. Successful configuration establishes the active address policy; acquisition remains a separate observation.
Each image name holds one complete current image in EROFS, a read-only filesystem format. Publication checks byte length and the content digest before atomically replacing that file. A machine already reading the old file retains its opened content. A later selection uses the content current at that point.
Discover
Observe the boot interface and temporary address through DHCP.
Declare
Assign the business address and select an image name independently.
Publish
Upload a complete image so waiting machines can select it.
Hand off
Grant the entry point permission after verification and preparation.
One execution grant within a boot
Bootstrap mounts the image as a read-only root, creates separate process and mount views, and prepares devices, kernel interfaces and writable runtime directories. The application entry point, /init, starts as PID 1, the first process in its own process namespace. Its image must contain all userspace execution dependencies.
Before the grant, a failed transfer or preparation must settle its I/O, mounts and child before selection can resume. Once the grant may have been delivered, that boot never starts a second application. Exit or missing readiness does not restore the execution opportunity.
| Resource | Owner | Meaning |
|---|---|---|
| Read-only root and runtime directories | Prepared by Bootstrap; used by the application | Runtime directories are writable; the image root remains read-only. |
| Address and resolver | The original DHCP client | Renewal and resolver updates remain visible to the application. |
| Persistent devices and service readiness | The application | Select devices, handle recovery and establish the service result. |
Separate declarations, observations and service results
Hardware reports independently capture CPU capacity, visible memory, hardware network interfaces and whole block devices. Each source can be unavailable; a successful empty capture has a different meaning. The controller keeps only the latest in-memory sample. Restart or eviction can remove a sample without making the machine disappear.
A completed publication establishes verified bytes and their published name. Bootstrap availability, maintenance SSH access, actual entry-point execution and business readiness each require their own observation. Changing an image or deleting a binding does not terminate an application already handed off.
| Observation | Established | Separate evidence needed |
|---|---|---|
| Static declaration stored | Address policy committed and activated | The client has acquired the matching lease. |
| Image published | Complete bytes bound to a name | The image mounts and the application runs. |
| Latest hardware sample | Facts captured at that observation | Application and storage operations are currently healthy. |
Check the facts in order when replacing a machine
To retain a business address while replacing a machine, first establish whether the old lease is still valid, then compare the new interface declaration with its actual lease. Deleting configuration neither retracts an issued lease nor terminates a running application. Excluding concurrent business activity remains an application or operational responsibility.
If the new machine is waiting, inspect its current binding and the complete image. After handoff, inspect the application’s boot identity, business response and known persistent data. Republishing the same image name changes later selections; it is not an implicit restart of the current application.
Supported conclusion: the application reads its known data
This supports the observed business result in the current environment. Preserve the relationship between the machine, address and expected data.
Unsupported conclusion: reachable SSH means service recovery
SSH establishes the maintenance path. Publication, an address declaration or an available bootstrap system also cannot establish completion of the application’s task.
Check next: a missing hardware sample
Distinguish an unavailable source, a successful empty collection and an emptied controller cache before deciding what to observe again.
Complete the chain with the application’s own output
The specified verification chain starts with DHCP discovery of an unknown interface and covers firmware boot, actual interface selection, runtime integrity, renewal by the original DHCP client and independent application output. A replacement-machine scenario checks the same business address and known bytes on persistent volumes.
These are verification requirements, not execution records for a particular environment. Maintenance reboot uses separately authorized SSH. A lost connection can leave the result unknown; a new boot and an application response must establish reboot and recovery independently.