Dracut, dmsquash, and overlays

[John Florian]

> -----Original Message-----
> From: devel-bounces at lists.fedoraproject.org [mailto:devel-
> bounces at lists.fedoraproject.org] On Behalf Of Major Hayden
> My goal is to live boot our servers since the majority of our systems would be
> stateless.  Being able to reboot into a known good, tested state would be
> advantageous.

I'm doing just that with my own custom Fedora Live spins that now runs on nearly a thousand "nodes".  I can kill any of them by exhausting the overlay space, but I avoid that issue by careful configuration of running services to ensure that anything[1] that gets written hits either tmpfs or my backing storage -- which in my case that happens to be various forms of Flash memory cards (CF, CFast, SD, or even SSD in a few cases).  Other than that data, the image is only semi-mutable.  Yes you alter things because of the overlay, but reboot and your back to square one.  This works great for us because I can apply an updated rpm or the like between spin releases yet maintain the robustness of a live image.

If you wish to discuss details and/or share lessons learned, tricks, etc. you may mail me off list if you wish.

[1] By "anything", I really only mean stuff that's being written on an on-going basis (e.g., logging) or stuff that's beneficially cached (e.g., yum data).  Not only do I avoid exhausting the overlay, I also gain reliability against network outages for some use cases.  This matters a lot to me since my spin is relatively use-case agnostic; it's an generic Appliance OS and puppet makes each node into something specific at run-time though always starting from a common image.
--
John Florian