Launch FAQ: Does Fedora CoreOS embrace the Container Linux Update Philosophy?


#1

The CoreOS Update Philosophy stays as important to us as always. Yes, Fedora CoreOS comes with automatic updates and regular releases. Multiple update channels are provided catering to different users’ needs. It will introduce a new node-update service based on rpm-ostree technologies, with a server component that can be optionally self-hosted. Failures that prevent an update from booting will automatically be reverted.


#2

Hello! It’s good to see that FCOS will continue the CoreOS update philosophy, but after reading the Disk Layout discussion in the issue tracker, I see the plan is for a four-partition disk layout. Does that mean that the USR-A/USR-B design used by CoreOS will be dropped in FCOS? Or is the scheme described there only for an initial generic dd install, after which Ignition could be used to set up something like the CoreOS nine-partition layout (or something else)? I ask because the A/B (or something equivalent) is pretty important for automatic updates in a large, geographically distributed cluster. Thanks!


#3

Does that mean that the USR-A/USR-B design used by CoreOS will be dropped in FCOS?

Yes. There will be no A/B scheme at the partitioning level.

Or is the scheme described there only for an initial generic dd install, after which Ignition could be used to set up something like the CoreOS nine-partition layout (or something else)?

No, we expect all nodes (both freshly installed and upgraded ones) to follow the partitioning scheme drafted in the design document you linked.

I ask because the A/B (or something equivalent) is pretty important for automatic updates in a large, geographically distributed cluster.

Indeed. The keyword here is “something equivalent”: rpm-ostree can handle the same semantics (multiple /usr deployments with auto-upgrades and rollbacks) at the filesystem-object level instead. That is, it doesn’t need multiple partitions and could scale to more than one passive /usr deployment.


#4

Thanks for clarifying that. Off to do some research on rpm-ostree! I imagine it will all be easier to comprehend once I’ve built things a few times. With that in mind, though, what would be a good path toward understanding how all this fits together? Maybe try building Atomic? Thanks!


#5

You can play around with Atomic Host in a VM, for example. Or try Silverblue, which is just the new name for Atomic Workstation aka an rpm-ostree for the desktop.