How the reconcile loop works
Fetch, observe, plan, validate, apply, report — and why configs are never edited in place.
Every agent runs the same loop, for ever, whether or not anything changed.
The six steps
- Fetch — pull the manifest version this node should be running.
- Observe — read what is actually on the box. Not what the database believes; what is there.
- Plan — work out the difference between the two.
- Validate — render the change to a staging directory and check it before anything live is touched.
- Apply — swap it in, keeping the previous version for rollback.
- Report — send back what happened.
Configs are never edited in place
This is the rule that makes validation meaningful. A new config is rendered beside the old one, checked, and then swapped. A config that would not start is refused before it can take every site on the node down with it, and the previous version is still there to roll back to.
What this gives you
Drift correction. Someone edits a file by hand during an incident. The next cycle restores it, and it shows up in the report rather than being discovered months later.
Crash recovery. A node that comes back converges to the state it should hold. There is no partially-applied change to unpick, because applying is a swap rather than a sequence of edits.
Rebuild from bare metal. Reinstall the machine, enrol the agent, and it converges. This is the same path as any other change, so it is exercised constantly instead of being a procedure you discover is broken on the worst day of the year.
If the control plane is unreachable
Nodes keep serving. They hold their manifest, and the sites on them do not depend on the control plane being up. That is the point of the agent pulling rather than the panel pushing.