Stateless Linux is not a deployment model. It is not any single technology.
It's a new way of thinking about how a system is supposed to run and be
managed.

To be stateless, a system should be able to be replaced at any time,
whether it's running diskless or with local storage. Hard drive crash? Just
resync your remote image to a new drive, and you're good to go. Server
goes offline? Start a new virtual instance running your OS image
off of your network storage.

Moreover, it's about being able to run multiple machines from identical
OS metadata. Instead of managing each machine independently, the single
copy of the OS metadata is managed.

Mailing Lists

Usage Cases

Server usage: a farm of machines instantiated and updated via a single copy of OS metadata

Virtual server usage: same as above, but they don't even need to be physical machines

Corporate desktops with local storage - stateless images are instantiated to a local disk from shared OS meta and run from there. This includes desktops (local swap, read-only root, and network homedirs) and laptops (local swap, read-only root, and local homedirs that need synced back to centralized network storage for backups.

Thin clients using NFS root, with or without local storage for swap, scratchpad, etc.

LiveCDs - a live CD is by definition stateless

Component technologies

Currently we're working on stateless enablers, that allow
administrators to deploy machines according to a stateless model.

We have changes that affect how the OS runs its root filesystem:

Read-only root support - all the system partitions are mounted read-only

Root can be on a local disk, NFS, NFS loopback or iSCSI

Temporary areas can be on a local disk, tmpfs or NFS storage

Files/directories which must be writable for proper operation are either bind mounted or provided via unionfs backed by the temporary storage areas

Any of these can be deployed with Xen to be used in a virtual environment

Persistent state (such as SSH keys) is managed by puppet. Effectively this allows the master copy of persistent state to live and be managed on the server and be cached on the stateless client.

We have changes that make it easier for multiple different computers
to run a single OS image:

Automatic hardware configuration that loads all relevant modules at boot

Automatic configuration of X, including monitor and input devices

Network and printer configuration for desktops that doesn't need the root password

We're also looking at certain areas for the future:

The ability to have a network-based image automatically synced to a local disk to enable disconnected mode.

The ability to sync local disk back to the server (/home for disconnected laptops)

The ability to use local disk as a persistent cache for network filesystems.

How do I test and deploy stateless images?

Not currently covered

changes to applications configuration mechanisms for getting configuration data (such as switching app configuration from local files to LDAP)

stateless-specific provisioning tools

The current working assumption that anything we would do in this space:

would be rushed and incomplete in the time needed to make FC6

would not work with current or future management tools without changes

would not integrate well into users' current management frameworks

Hence, these spaces are best left to development in the context of the future management system. What we're concentrating on for FC7 is the basic infrastructure.

FAQs

1. How do I make my app work with stateless?

Generally, if it avoids writing to the root filesystem, it should be OK. For configuration, we're doing configuration on the raw source images themselves (whether via chroot, via booting the image in Xen, or various other methods); this means that config files should be OK, as long as you're not expecting the client systems to write to them.

2. What architectures are targeted for this?

Initially: x86, x86_64

Additional arches if time permits: ppc

Server architecture only matters in that if you are modifying a (for example) i386 stateless image, whether by chroot() or Xen, you will need to do this from an architecture that can run i386 binaries.

3. How does this interact with SELinux?

SELinux should work without any significant modifications, provided the underlying filesystems support it. (This is not currently the case for NFS, or for the various filesystems used by LiveCDs.)