To date, we've successfully pushed 38 versions of CoreOS out via our update service. Because of the filesystem switch, it's not possible to release these changes as an update. We will be providing new images for all platforms and have Amazon EC2 , Google Compute Engine, Openstack and Vagrant images available today.

These new images represent the first release on a path that ends at a stable, production-ready CoreOS.

New filesystem layout

The largest change was modifying our read-only root file system. In the current images, directories like /etc reside on the read-only partition because they contained parts of the OS that needed to stay in a known state in order to update them safely. We undertook a large effort to move all of these files into /usr, which now contains all of the critical files needed to operate the OS and is the only read-only portion of the filesystem. Every package that expected a hard-coded path to a file in /etc has been modified and moved into /usr. If you would like to provide your own version of a file that resided in /etc, you can now place it there and the OS will use it, instead of the one we provide by default.

With this change, systemd unit files now live in the standard location in /etc/systemd/system instead of within /media/state/units. When creating a unit, you can simply run systemctl enable foo.service.

Docker 0.9 and btrfs

With the switch to a read-only /usr/, we also switched the rest of the filesystem to btrfs. This means you can now use Docker 0.9 with btrfs (which is much faster!), and any other native btrfs tools you might need (snapshotting, replication, etc). One unfortunate side effect of this change is that all Docker containers will need to be reinitialized on CoreOS (docker pull, or docker build). Docker does not provide any mechanisms to migrate between AUFS and btfs. We do not expect needing to make breaking changes like this again in the future.

As a result of a read/write /etc/, you can now easily modify docker.service to enable the docker remote api or tweak any other flags you wish. You can overwrite this file on disk manually or modify it on boot with cloud-config, as introduced below.

CoreOS CloudInit and cloud-config.yml

All CoreOS platforms going forward will use CoreOS CloudInit and the accompanying cloud-config.yml to configure the OS while it boots. Our goal is for you to be able to use the same cloud-config.yml to bootstrap CoreOS on any mix of platforms.

Create the user "penny" and set the ~/.ssh/authorized_keys to the same public keys as the github user "bcwaldon"

The exact same cloud-config.yml can be specified on any platform that CoreOS supports. For example, on Amazon, you would paste it into your user-data. On OpenStack, you use config-drive, but can place the identical cloud-config.yml you pasted into Amazon user-data. CloudInit also used during our OEM/distribution process to configure networking with networkd and other settings per platform (depricating the /run convention).

The CoreOS alpha will still be a bit bumpy as we slim things down and make final tweaks to the alpha. However, the release puts us on the critical path to a beta, and a subsequent stable release in the next few weeks. We'll be updating all of the documentation over the next few days and release new images to support for the rest of our platforms.