-----Original Message----- From: devel-bounces@lists.fedoraproject.org [mailto:devel- bounces@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