Poettering: Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems [LWN.net]

Poettering: Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems

Posted Jun 17, 2014 22:51 UTC (Tue) by jspaleta (subscriber, #50639)
Parent article: Poettering: Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems

You know what I would like to see...

An analysis of the systemd approach to stateless from the point of view of the goals of the "stateless linux" whitepaper Havoc put together:
http://lwn.net/Articles/101900/
archive of the referenced whitepaper here:
http://citethisbook.net/Red_Hat_Introduction_to_Stateless...

In the nearly 10 years since people put their heads together and tried to write down a set of requirements for a stateless scenario...what's changed in terms of the target requirements? Since the original concept document was pre-cloud, I think its an interesting question. And well, I think its important to remind the youngins that stateless was a desirable goal even in the pre-history before "The Cloud {tm}" and that systemd isn't introducing something new here. What its introducing is hopefully more optimal way to get to stateless, and that stateless as a deliverable has been desired for a long time.

Obviously cloud and containers are a drastically more vital use case to driving towards statelessness as an out-of-the-box deliverable. And systemd is absolutely going to make sure that new use case is covered. But I have to wonder, has the fundamental requirements changed at all in the last decade since Havoc put the concept whitepaper together?

-jef

to post comments

Poettering: Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems

Posted Jun 17, 2014 23:34 UTC (Tue) by clump (subscriber, #27801) [Link]

Stateless, still enjoying use in mainframe and HPC worlds, is hard to do properly. Enterprises have moved to virtualization and templates. There is far more overhead with a virtualized approach, but cpu, disk, and provisioning time are cheap enough. Easier, but not necessarily better.

Large scale deployments and cloud do make the stateless use case more interesting. Overhead is more expensive.

Docker has an interesting approach. Rather than messing with startup on the operating system, Docker discards the entire instance unless it's committed or kept running. Docker processes are "stateless" unless you'd like to commit them.

systemd and Docker have very different responsibilities, of course.

Poettering: Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems

Posted Jun 18, 2014 1:42 UTC (Wed) by sjj (guest, #2020) [Link] (2 responses)

Thanks for that historical link. I for one welcome our new stateless overlords!

We've certainly moved a lot closer to stateless, in a kind of ad hoc way. Only some greybeards remember manual mknod in /dev, and even hand editing stuff in /etc on a modern linux laptop is becoming a lost art due to sensible defaults and autoconfiguration.

User data is scattered around the world, in islands in the cloud. Enterprises haven't bothered backing up user machines in years - they give you a network share or a Box account and it's your responsibility to copy stuff you want to keep. I would love a distributed filesystem I could use on a laptop though - connect to network and let it sync, detach and go.

Sysadmins who ssh to servers and edit files locally are going to find themselves unemployed. If it ain't in git, it might as well not exist. Server applications need to start looking for some service discovery mechanism for configuration.

Exciting times, and I'm glad there are people willing to push the envelope against the always-somewhat-surprising conservatism of some techies.

Poettering: Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems

Posted Jun 18, 2014 4:23 UTC (Wed) by jspaleta (subscriber, #50639) [Link] (1 responses)

I actually don't think this is ad-hoc. I think historically 2004 was sort of a watershed year for really really thinking hard about the state of things and picking a direction and a set of goals to shoot for.

We have Havoc's whitepaper on stateless _and_ 2004 was also the year we saw people band together and form up Project Utopia and start really addressing the need for dynamic hardware management.

I think systemd (and even upstart may it rest in peace) is actually part of an... intelligent design (NOT natural evolution! HA!)... of code implementations around some fundamental goals generated in the 2004 timeframe. No not ad-hoc at all... but a systematic and cyclical process implementation, refinement and eventually replacement with better implementations to better meet the goals as laid out way back in 2004.

I really don't see the container or visualization as being anything really new as a use case that wasn't provided for by the goals of Stateless Linux and Project Utopia together in 2004. Containers are an interesting use case only because its clearly becoming a dominant use case now, very quickly, and a usecase that benefits greatly from stateless. Whereas previously the uses cases that could really benefit from stateless were more niche.... well manicured thin client islands among a wild sea of fat clients in 2004.

But it does beg the question, is work towards "Stateless Utopia" a positive feedback loop? Sorry here comes the run on sentence that will bake your noodle...

As the people working towards a Utopic Stateless Utopia, got better at meeting the goals with newer code implementations, did their work make it easier for admins to move their workloads to configurations that depended on aspects of Stateless Utopia, in turn raising demand (and therefore the value) for even better Stateless Uptopia implementations?

I think perhaps that's what's happening. We've sort of hit the tipping point now in the last couple of years in terms of real world installs that benefit. And we've gotten here only because of the persistent development in the intervening years to just part of the way, dragging some of us kicking and screaming by our beards into the future.

-jef

Poettering: Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems

Posted Jun 18, 2014 22:40 UTC (Wed) by sjj (guest, #2020) [Link]

Yeah, I think you're probably right - it all just feels adhoccy from the sidelines since there is no Central Linux Planning Office with five-year plans, rather than diverse groups and individuals exploring solutions. Also, future history might value the invention and adoption of git as high as linux itself. No closed source company can match a loose collection of geeks with github accounts, filled with laziness, impatience, and hubris, bent on reinventing the wheel.

And some kind of tipping point is almost here. It's fascinating how we seem to be converging on a Linux From The Future (Project Atomic, CoreOS) with containers and service discovery tools.

If there are any anthropology grad students around, a dissertation on the design evolution of this part of the FLOSS world would be interesting to read!

/blowiating