 So my name's Dusty May by work for Red Hat and I'm here to talk about Fedora CoreOS today. So briefly, I'm gonna talk about what is Fedora CoreOS. I'm gonna talk about some of the features of Fedora CoreOS, how it relates to RHEL CoreOS and also how does it relate to OKD. Okay, Fedora CoreOS, what is it? It's an emerging Fedora edition. It came from the merging of two communities. One was CoreOS Inc's Container Linux community and also Project Atomic's Atomic host community. It incorporates the Container Linux philosophy or what we've been referring to as the Container Linux philosophy, the provisioning stack and the cloud native expertise of Container Linux. And it also incorporates Atomic host Fedora Foundation, the update stack and the enhanced security with SC Linux. So first, I wanna talk a little bit more about the philosophy behind Container Linux because it really has driven what we've done with Fedora CoreOS. So first off, Container Linux focused primarily on automatic updates, which means that the administrator by default has no interaction with the system in order to keep the system up to date. And the goal there is that staying up to date in a default automated manner means that security fixes get automatically applied and your systems stay more secure. So more secure by default. Container Linux also had all nodes start from approximately the same starting point and they used ignition in order to achieve this goal. So you would use ignition to provision a node wherever it started, whether it be on bare metal or on cloud and they all essentially start from the same starting point. Container Linux also focused on immutable infrastructure. So for example, if you'd need a change, you're encouraged to update your configuration and reprovision. This kind of guarantees that your changes make it back into your configuration and it's tested because guess what? You've tested that provisioning when you brought up a new node. Also, user software runs in containers, which means that applications don't depend on the host and the host updates are more reliable. When you have automatic updates, you need them to be reliable. So now we're gonna talk about Fedora Core OS and you're gonna hear a lot about that, those features that I just mentioned or the philosophy I just mentioned. The first one being automatic updates. So Fedora Core OS features automatic updates by default and if you have automatic updates, you need them to be reliable. How do we achieve this goal? So we achieve this goal by having extensive tests in automated CI pipelines. We also have several update streams, which I'll touch on in a minute, that allow users to preview what's coming. Users run the various streams so that they can know when changes are coming that they need to either address or report issues for. We also have managed upgrade rollouts. So upgrades, upgrade windows happen over several days. If people hit issues early in the rollout window, they report them and we can address the issue, stop the rollout window if we need to. And then of course, things will go wrong at some point. For when things go wrong, we have RPM OS tree rollback, which can be used to go back to the previous version. And in the future, we plan to have some sort of automated rollback functionality where a user can specify, hey, if this particular health check doesn't pass, I want you to automatically go back to the previous version before this update. That's a future feature, not something we have just yet. Okay, I mentioned multiple update streams. Right now we have three update streams, which we offer that have automated updates. One is next. That stream is focused more on experimental features or Fedora major release rebases. So for example, when we switched to C Groups V2, right now we're on C Groups V1 in Fedora CoreOS. When we switched to C Groups V2, we will land that in the next stream first. It'll have some soak time there. Hopefully people report any issues, we get them fixed. And then eventually they'll go into testing and stable. Also for example, when we switch from Fedora 32 to Fedora 33, that will happen in next first. So it's an opportunity for us to put those breaking changes that are gonna happen or possibly breaking changes that are gonna happen in there and get them tested. Okay, so testing is basically a preview of what's coming to stable. It's a point in time snapshot of Fedora stable RPM content. And that is going to go directly into stable in two weeks if we don't find issues. So the goals of having these update streams are to publish new releases into update streams every two weeks and also find issues and get them fixed so they don't hit the stable stream. The Fedora CoreOS release promotion, I touched on this briefly. We have a version number that basically incorporates the Fedora major. The date at which content was snapshotted from Fedora stable repos. And then also a number that indicates which release stream we're on. So we have three release streams. We have testing stable and next and that number corresponds to a release stream. And then we have a revision. So if we do an ad hoc fix to a content set we will bump that revision number and re-release. So for the YUM repositories, if this represents the YUM repository moving in time, we will snapshot that on in this case, the 23rd of March, that becomes the testing stream. We do a testing stream release and then hopefully we don't find any issues. Two weeks later that gets promoted to stable and people in the stable stream get that content. Okay, the next feature is automated provisioning. So Fedora CoreOS uses the ignition to automate provisioning just like container Linux did. Any logic for machine lifetime is encoded in the config. So it's very easy to automatically reprovision nodes. An example of this is earlier this year. I have a node sitting on my desk in the office that runs Fedora CoreOS and it also happens to be an IRC client server setup that I have. Yet I lost power to it at some point and it didn't turn itself back on. So I wasn't able to get to it and I also wasn't able to get into the office because of COVID. So I took the configs that I used to bring up that server and I just spun up of the YUM at home and I was back up and running in 10 minutes. So that's an example of, because everything is baked into these ignition configs, it's really easy to get a new node up and running in the same profile as the one that you had. And then because we're using ignition, we have the same starting point, whether we're on bare metal or cloud, we use approximately the same image everywhere. So because we can use ignition everywhere as opposed to kickstart for bare metal and cloud init for cloud, it kind of unifies the whole experience. Okay, so the details of ignition. Ignition is a declarative JSON document. It's machine friendly, so not very user friendly unless you like to read JSON. It runs exactly once during the init remfs stage on boot. It can write files, system to units, users, groups, partition, disks, et cetera. The key point here is if provisioning fails, the boot fails. So you don't end up with a half provision system. Sometimes with cloud init, you could have part of it succeed and part of it not succeed and then you've got an application up that's half running. With ignition, it's good because you know the machine didn't provision correctly, but it also can be bad because it's hard to debug in the init run fast. So there's good and bad there, but we like it overall. Particularly ignition is not very human friendly. So we have a tool called the Fedora-CoreOS config transpiler that is a lot more human friendly. It's written in YAML, and it also has some what we call sugar on top that will automatically write out some of the more tedious parts of ignition for you. So the next feature I'd like to talk about is basically cloud native and container focused. So software runs in containers and users have two options. They have Podman or Moby Engine, which is also known as Docker. Those two container run times, if you're coming from container Linux, you still have Docker if you wanna use that or if you wanna try out Podman that's there for you. It's ready for cluster deployments. So you can spin up 100 nodes and have them join a cluster because ignition configs are used to automate the cluster join, it kind of takes care of everything for you. And then you can spin down nodes and spend them up again as you need. So that's kind of more of the cloud native piece of it. It's also offered on a plethora of clouds and vert platforms. So we're trying to be on any major cloud platform and we're adding new ones every day. OS versioning and security. So this is one that I'll dig into a little bit. Fedora Core OS uses RPM OS tree technology. I like to describe it as like get for your operating system. So we have, for example, a particular version of Fedora Core OS, which is kind of like a tag. You have a version and also a get commit, or sorry, an OS tree commit hash. And this single identifier tells you all the software that's in a particular release. It tells you all the RPM content, tells you all the config default settings that are delivered. And that is important when you are trying to report issues or share information. So as a user, you can report an issue and say, hey, I'm on this specific commit of Fedora Core OS and I run these steps and I see this problem. And that's really powerful. Because it uses RPM OS tree, it also has read only file system mounts, which prevents accidental OS corruption. So if you happen to RMRF on the wrong directory, and it also prevents some, you know, novice attacks from modifying the system. We also have SE Linux enforcing by default, which prevents compromised apps from gaining further access, which is not something that container Linux had. Okay, so what's in the OS? We have the latest Fedora-based components built from RPMs. We have hardware support. So hopefully anything that Fedora supports, we can support with Fedora Core OS. We have basic administration tools. We have container engines and not much else. So we don't have Python. The goal here is that we encourage users to run their applications in containers and not run things directly on the host. That makes our updates more reliable. We don't want to update the host and break your application. Okay, so coming soon, we have more cloud platforms that we're adding. We also are trying to get support for multi-arch. We've got more, you know, human friendly helper functions that we wanna add to Fedora Core OS config transpiler. We wanna make our package layering more reliable in cases that might need that. We want to have more slash improve documentation and then also tighter integrations with OKD. When you talk about Fedora and RHEL Core OS, you wanna know what's the difference? So at a high level, the biggest difference is obviously based on RHEL package set versus based on a Fedora package set. But probably the larger thing is, Red Hat Core OS is only designed or meant to be used directly with OpenShift itself and not meant to be used standalone. So the updates for Red Hat Core OS are delivered and controlled by the cluster itself and not independently of the cluster. With Fedora Core OS, you can use it either standalone or you can use it as part of a cluster. So for example, with OKD. In the standalone case, you get the updates directly from Fedora Core OS' release servers. In the case of OKD, you get the updates similar to how Red Hat Core OS gets its updates from containers in a registry. So you can use Fedora Core OS standalone with other cluster orchestration technologies or with OKD. Okay, specifically OKD is installable with OKD's installer. So the same one that OCP uses, OpenShift install. The cluster controls the OS upgrades. As I mentioned a minute ago, upgrades are provided as machine OS content containers. And then the cluster can manage and bring up new machines automatically, which I think is the coolest point there right at the end. If you wanna go just grab Fedora Core OS or view our releases, we have the top level get fedora.org slash core OS. For any issues or kind of design discussion related stuff, we usually open tickets in our Fedora Core OS tracker. So that's github.com slash core OS slash fedora dash core OS dash tracker. So you can open an issue there and that's where we can kind of dig into the details of the hardware rate controller support. And we also have a forum. If you have kind of like a more of a user related question related to, I can't, how do you set a password or things like that? The forum's a good place for that. We have a mailing list and we also have Fedora Core OS on FreeNode.