MicroOS transactional-update vs Ansible: /etc config persistence across atomic snapshots

MicroOS transactional-update creates a new btrfs snapshot per atomic deployment, activating on reboot. Persistent /etc subvolume survives snapshots but isn't integrated with the update pipeline. When a package update replaces a config‑owning file such as /etc/nginx/nginx.conf, the new snapshot has the package default while /etc keeps the modified file. No automatic merge, no .rpmnew/.rpmsave artifact, no runtime warning; admin must manually diff and reconcile after reboot.

Ansible and Salt operate on mutable roots, working on Leap/Tumbleweed but not MicroOS, where writes go to a snapshot that may be discarded on rollback or fail to persist across updates. The /etc subvolume integration does not track changes as OS state, leaving config drift undetected and unmerged between live system and staged snapshot.

systemd‑sysext extension images ship /etc overlays as squashfs merged at boot but require rebuilding on every config change, offer no live reload, and have no standard tooling to integrate Ansible or Salt output into sysext images. This leaves an unresolved interoperability question for declarative config management on immutable‑root systems.

• Under what conditions does the persisted /etc subvolume override the snapshot’s default config at boot?
• Is there a supported mechanism to inject Ansible‑ or Salt‑rendered config into the transactional-update pipeline without rebuilding a systemd‑sysext image?
• How does MicroOS detect and report config drift between live /etc and the snapshot’s expected /etc after an atomic update?