> -----Original Message----- > From: devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx [mailto:devel- > bounces@xxxxxxxxxxxxxxxxxxxxxxx] 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
