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.


#6

I will check those out. Thanks!


#7

So I have a few more questions. I’m looking now at Atomic Host in a VM, and noticed that the OS version (“Fedora 29.20181210.0”) contains a tag identifying the version of Fedora that this version based on. I read in the Design document that FCOS versions will be “unversioned,” and not carry such a tag. I’m guessing that decision is based on some problem experienced with Atomic, but just wondered why? It does seem like somewhat useful information when, for example, I want to build a containerized application, and need to decide which Fedora repo to use for the packages. To avoid subtle incompatibilities it seems like it would be wise to build the container using the same packages that FCOS is based on, but without the tag I have to rely on lore… knowing the release schedule, etc. Perhaps it’s not supposed to matter but inevitably at some point there will be a kernel ABI change that makes it significant.

Also I’ve been trying to work out the exact relationship between the “next,” “testing,” and “stable” channels, particularly around the time that a new version of Fedora is released. I imagine the first release next May will be kind of weird, but if you think about the Fedora 31, to be released on/about 31 October 2019, will the version that gets promoted to “stable” at that time come from “testing” or from “next”? Or maybe the version of “next” at (Release-4W) gets promoted to “testing” for (Release-2W), which then becomes stable at (Release-0)? I’m just trying to get it all clear in my mind because I have to explain it to people.

Thanks!


#8

I’m looking now at Atomic Host in a VM, and noticed that the OS version (“Fedora 29.20181210.0”) contains a tag identifying the version of Fedora that this version based on. I read in the Design document that FCOS versions will be “unversioned,” and not carry such a tag.

The doc is talking about OSTree refs, meaning that there will not be separate stable-f30 and stable-f31 streams. Instead, stable machines will automatically update from F30 to F31 when the stable stream is rebased. OS releases will indeed have version numbers, and discussion of the versioning scheme is happening in this ticket.

It does seem like somewhat useful information when, for example, I want to build a containerized application, and need to decide which Fedora repo to use for the packages. To avoid subtle incompatibilities it seems like it would be wise to build the container using the same packages that FCOS is based on, but without the tag I have to rely on lore… knowing the release schedule, etc. Perhaps it’s not supposed to matter but inevitably at some point there will be a kernel ABI change that makes it significant.

In general, your container images shouldn’t need to be synchronized with the Fedora version of the host. You’re right that subtle kernel ABI issues are possible, but that problem shouldn’t be any worse with Fedora CoreOS than with any other host of containerized workloads.

if you think about the Fedora 31, to be released on/about 31 October 2019, will the version that gets promoted to “stable” at that time come from “testing” or from “next”? Or maybe the version of “next” at (Release-4W) gets promoted to “testing” for (Release-2W), which then becomes stable at (Release-0)?

Yeah, the design doc doesn’t make that especially clear. Here’s what I was thinking when I wrote that section:

  • At some point after the release of Fedora 31, we decide to rebase Fedora CoreOS onto it.
  • After the rebase, the next in-cycle release of testing will draw packages from F31 instead of F30, and will promote normally to stable after two weeks.
  • After the rebase, the next in-cycle release of next will be an exact copy of the concurrent testing release, except perhaps for kernel packages. next releases will continue to mirror testing (modulo the kernel) until Bodhi is enabled for F32.

In other words, next is a rough preview of what will eventually land in testing, but next releases never promote directly to testing.


#9

Thanks for clarifying that and the mixup about the naming of “refs.” I still have a lot to learn about how all this comes together.