 Hi, everyone, thanks for having me. All right, yeah, my talk is the Roto OKD4 operators, F-Cos, and Kubernetes. So let's have a quick look at the agenda. What is OKD4? This will be the first point. Then I'll quickly talk about F-Cos Fedora CoroS. We'll have a very short preview demo. And then I'll pitch to you that you should try out OKD4. Then we'll have a quick look at the road ahead, the roadmap, and also what's next in OKD. And then I'll pitch the OKD working group, which I'm chairing together with Diane and Danny Komnia, who is our community chair from outside of Ratat, who isn't here, I think. Yeah, all right, let's get started. What is OKD4? OKD4 is the origin community distribution of Kubernetes that powers OpenShift. It's not an acronym. That's very important. It just means that. It's the OpenShift code base plus Fedora CoroS. So we built essentially off of the master branches. So what OKD4 is right now is what OpenShift 4.4 will be at some stage, essentially. We built off of the masters. Yeah, and plus Fedora CoroS. And there's a little star there. It could be any operating system that is built with the RPMOS tree and ignition technologies. I'll dive into that in a bit, a little bit more as well. So if you want to check out OKD4, go to okd.io. And you'll land on this page. Yeah. All right, so this is a slide. I think we had a similar one in an earlier talk already. So this is OCP, the product. And as you can see, if I go to the next slide, there's a little difference there. We switch out the operating system, which in the product, OCP, is RATET CoroS, or REL CoroS. And here it is Fedora CoroS. So that's the main difference. We use the same OpenShift code base, but the operating system is different. What's very cool in OpenShift is that we update the operating system through the cluster and we just bind the lifecycle together so the operating system becomes an implementation detail. So here we switch out the REL CoroS with Fedora CoroS. So what's Fedora CoroS, then? The mission statement of Fedora CoroS, I'll just quickly read it out. It's an automatically updating minimal monolithic container focused operating system designed for clusters but also operable standalone, optimized for Kubernetes, but also great without it. So while REL CoroS is just focused on that one use case as a cluster, Fedora CoroS is also operable standalone and can run just container workloads on a single node without the cluster. So Fedora CoroS is a new Fedora edition. It's an automatically updating Linux OS. It's purpose-built for running containerized workloads at scale. It's composed out of Fedora RPM packages. It is based on RPM OS tree and ignition and more on that again in a second. And it's combining the CoroS philosophy and project atomic technology, all of our learnings we've taken from project atomic and then the philosophy of CoroS container Linux that came in with the CoroS acquisition alongside the ignition technology, for example. So maybe I'll just dive into what ignition RPM OS tree is a little bit more. I'm technical, so if you get bored with this, I'll skip this quickly. I'll keep it short. So ignition is our declarative first boot configuration system. So we have a declarative config, the ignition config specification. And on the very first boot after provisioning, it'll set up the system as needed, like in what cloud am I running? What do I need to configure here? So ignition will do that for you on the very first boot. And then we take the same configuration and have it managed with an operator for day two operations. So it's a very intricate and very, very cool system. And that essentially allows us to have our clusters run autopilot with all the operators. RPM OS tree, on the other hand, is the base for our immutability. We compose images out of RPM packages and have a semi-immutable system where you can only write on parts of the file system, while the rest is totally immutable. And then an update will happen by downloading a new OS tree commit, laying that onto disk and booting into that commit. And on traditional Fedora, well, on Fedora CoreOS, you can actually roll back. We don't support that in the cluster use case. A rollback would be an update to the older version, sort of updating to the older commit again. So there's only, yeah, there's no going back in that graph. So, yeah, what's the difference with RATAT CoreOS? Again, RATAT CoreOS is a component and implementation detail of OpenShift. It updates alongside OpenShift. There's only one lifecycle. You don't really notice anything about the update that's happening to the operating system. And as opposed to Fedora CoreOS, RATAT CoreOS is based on the rel package set. So let's quickly switch to the preview demo. So we're in preview state right now. It's like an alpha, maybe almost beta. And I have a cluster spun up here. So as you can see, we have different branding. It's OKD instead of the OpenShift one. So the main difference is let me quickly dive into the node details. Just to show you, we're running on the OS image Fedora CoreOS, which just got a little bit small, maybe. So Fedora CoreOS was just released stable. I think last week. So we're running on that. And then as we're building off of the master branches, we already use Kubelet 117.1 and Cryo 117 as well. One important difference is that you'll notice as a customer trying this out. On the operator hub, you'll have access to the community operators. You don't have access to the RATAT operators. But all of them have their upstream operators, which you can install through the operator hub. So on the operator hub, you will find all the community operators. All right, let's switch back. Now my pitch. Try it out. Please give us feedback. And the difference between OKD or Origin 3.11 and OKD4 is that we're based on Fedora now, just to be based on Sentos. But for us as RATAT, it's very important to get that early feedback running the cluster on the newest kernel, on all the newest tech that is out there. And we really want that early testing and early feedback to improve the product later on to have feedback and changes naturally trickle down from OKD, from the master branches, into the product. And that wasn't really possible with OKD 3.X. Now it is possible. So go to OKD.io. Go to the Download section and download it. We have a release page where you can find all the CI builds of OKD and try any of them out, preferably a green one. Otherwise, you might not be able to test anything. And then give feedback. We have two repositories, actually. One for the technical feedback, which is this one. GitHub.com slash OpenShift slash OKD. So if you find anything, any bug on OKD, we will file it there. We will triage it and send it to the responsible team internally to have it fixed as soon as possible. Let's get to the road ahead. So we created an OKD for road map together with the community, with the OKD working group that formed about half a year ago. And we had some general guidelines in there. That is, we'll use Ignition v3. Right now, OCP still runs with Ignition spec v2. We'll use Ignition spec v3 because we'll get there with the product soon, but we want to get that early testing again. And then we'll have one OS we always want to support, which is Fedora CoreOS. We're open actually to supporting more of helping other communities get their own OS into OKD and use it as a base for OKD. Again, as Rathad, it makes most sense for us to just use or focus on Fedora here. But there is a path to create a sub-working group. For example, if you're with the open Susie community and you want to use that operating system as a base for OKD, there's a path for you to actually get that sort of going and talk to the working group. And there's a process for that. So there's a few general guidelines. And then we had the phase zero, which was get the first alpha out. And we've done that. So we're in phase one right now, which is sort of more of a stabilizing phase. It's still pretty much internal. You can't really participate and contribute a lot. But once we go GA, it will be in phase two. And then we'll also revisit this roadmap. And in phase two, we want to really focus on community collaboration and technology incubation. Meaning that if you have any ideas for features or you find bugs early on in OKD, we want to be the interface to Rathad externals to make collaboration actually possible. That was very hard with OKD 3.x. And there was lots of room for improvement there. So with your new OKD working group, we really want to make that possible. And this is leading over to this part, the OKD working group. We have two repositories, the community repository, which is sort of for planning the meetings and everything organizational. And then we have the OKD repository, which is the technical one. So this is where you would file bugs. And we would, again, triage them and send them off to the right people to fix. You can find us on Slack. There is the OpenShift dev channel on the Kubernetes Slack. And we're also in the OpenShift users channel. So if you have a user-oriented question, go to the users channel. If it's really a dev question, we're in the dev channel. And then also the OpenShift comments Slack. You might be familiar with that. We're essentially in any channel there. I think we're on the general channel, definitely. And there is an OKD4 channel on the OpenShift comments Slack as well. We also have a mailing list in the form of a Google group. It's another annoying URL. You can copy down now. I'll just get the slides later. Join that group, and you'll be informed of everything that's happening, of our meeting agendas and meeting times. And you'll get the links to the recordings of those working group meetings as well. So come by and say hello. We're always open to new interested members that want to contribute. And is there anything more? Yeah, so we have two projects, Kanban projects, on GitHub as well. One in the community repository, which is, again, for planning out the meetings, setting the agenda. Diane manages that usually. So this is where you plan out the meetings. And you can see the agendas upfront. And you can even add ideas for the agenda. And then the other one, which is the OKD4 project. If you go to the OpenShift organization, it's the only organization-wide project there. And that, again, is for following the current status of development of the engineering work we do on OKD4. And with that, I'm already through. I think I haven't...