 Hi, I'm Christian Glombeck. I'm a senior software engineer at Ratat. I work in the OpenShift Arc, been on a couple of teams there currently on the specialist platform team that works on integrating new platforms, or adding support for new platforms and providers. And previously, I was on the machine config operator team and the core team. And I've also been co-leading the OKD working group for some time. And my name is Vadim Lutkovsky, I work for Redhead in the Edge group. And today we join forces to speak about our community distribution, which is called OKD. We'll start with doing an overview on what OKD4 is. Then we'll move on to more detailed features in its current state of the union for the OKD. Then we'll talk about how OKD fits into the whole ecosystem and what other features does it enable. The OKD is our community distribution of Kubernetes it's composed from the volunteers from mostly Redhead, but also other companies are being involved as they get to use most of the OpenShift code base. But instead of the Rail Core OS, we use the basis of the Dora Core OS. This decision was made so that we could streamline the contributions sooner into the end final product instead of passing it through the level of Dora than getting into Rail and then for the customers. You can find more information on the site called OKD.io. As you can see, the OpenShift is effectively OpenShift with a slight difference of branding, other than that the goal is to provide all the features that OCP has with an option for the community to participate and make decisions where the distribution is going. More into details of the current state. We're mostly focusing on a rolling release model where we have one single stream for consumers to use it. We're currently at release 4.10. The goal is to provide most of the features of the OCP without any requiring subscription. So we have a customized installer and machine config operator to make it run on top of the Dora Core OS. And a lot of features like monitoring, additional operators you're using, the operator hub, are also available. We also provide a contributing guide for the newcomers how to get involved into making changes, making your own custom OCP and we're actively helping community to get involved so that we would get an additional validation of what features we provide to humans. OCP also sits in between operator hub upstream and Fedora communities. So since we use Fedora Core OS, we also get all the new features coming in Fedora. And you can also make use of all the features coming in operator hub and participating in those communities using OCP as a starting platform. Another goal of the OCP is to get new technologies enabled preferably by default. For instance, OCP was the first distribution to use Segnation version 3 first. And now we are defaulting to C Groups V2 enabled by default before OCP does that. And there are smaller examples similar to that. And with that, I'll pass it to Christian. Thank you Vadim. Yeah, next up, the ecosystem. We don't just collaborate with the operator hub and Fedora communities. We collaborate with quite a few communities and have a few users that make use of OKD. One prime example you heard of today already is MicroShift, which right now, as it's not a product yet, uses OKD pieces to get built. And that's an interesting project. And yeah, one of the things we've kind of started or we're started within OKD and are now going to be productized. And obviously, that's very exciting to get to the edge and enable small scale deployments. And maybe in the future, things like AB availability, highly available AB deployments. We don't have a real cluster, but just two machines that back each other up. Then one interesting effort we're currently working on, which is kind of led by the Fedora CoroS community, is the CoroS layering effort. We're going to use that in OKD soon. We're not doing it yet. But that is going to enable you to create derived operating system images from the base OS tree, which in our case in OKD is Fedora CoroS. For the product, it would be Rel CoroS. And with this, you can actually use a Docker file to install more things into your image and create the image beforehand and then use it later on as the machine OS content image that is used as the machine config operator uses rights to disk as the operating system. So there's going to be a lot of interesting things going to happen happening with CoroS layering, because that'll just enable us to have a much easier development flow in comparison to what we have today with the current machine OS encapsulation, where the machine OS image is, you probably know this, you might not, we ship the OS as a container image, as a OCI container image. And then we have the machine config operator that extracts that OS tree, the directory structure, and writes it to disks. And we reboot into the new version. With this, it's going to be very similar, but the container that ships the operating system is actually usable just like any other container. Right now, we have a special encapsulation where you can't just use the machine OS container like a normal container with CoroS layering. You can actually use that OS tree image just as you would use any other container. So you can either boot it or you can run it as a container, which is pretty cool. And then you also just heard about the operate-first cloud. So we're going to collaborate with them. We're going to try to spin up a few OKD clusters. So you can also use them. I just want to really plug this operate-first. If you want to gain experience or get to know OpenShift in general or OKD, please do try it. It's great. And then we have actually two subworking groups in OKD. One is mentioned here. It's the docs working group, which has been very active and has been doing great work on our docs website. We actually built the docs from the same sources as the OCP, the OpenShift product docs. But obviously, there's a few slight changes we need to refer to Fedora and the OKD pieces instead of the rel pieces. We have a second subworking group, which is the virtualization subgroup, which came from the Overt community. And we want to provide essentially a way that subworking group wants to provide a way to migrate Overt workloads into OpenShift, into OKD. And that is built on Qvert. So that's the OKD virtualization subworking group. If you're interested in working with us, collaborating with us, or just getting to know the developers behind OKD or the wider community, we have the OKD working group. And everybody's invited to join. Check out OKD.io for the main website. Our docs are on docs.okd.io. We also have an issue tracker on GitHub, which is the OpenShift OKD repository. And then if you want to find us on chat for questions or anything else, we are in the OpenShift users channel on the Kubernetes Slack. And there's also a matrix channel on the Fedora project instance, which is the OKD channel. We also have a calendar that you can subscribe to. There's the bi-weekly OKD working group meetings on their anti-bi-weekly docs meetings. So yeah, if you want to join us, please go ahead and hit us up. I also want to plug the Fedora CoreOS working group if you're interested more in core operating system work. We have a liaison from the CoreOS group in the OKD working group, just as we have a liaison from the Machine Config operator in the OKD working group. And the Fedora CoreOS working group has their own meetings weekly on IRC. There's also the Fedora CoreOS tracker. So if you hit any issues with the base operating system or afterburn any of the tools that are part of the base operating system, then that's the right tracker to file things or just to track development of Fedora CoreOS. Yeah, there's a discussion forum on the Fedora forums. There's the mailing list as well. And again, the calendar for the meetings. And with that, we're already through. If we do have some time for questions, we'll take questions if there are any. Otherwise, thank you very much for listening to us. So I just have a quick question. Because we have a raging debate between Slack and Matrix. That's been the latest thing. We're going to bridge those. We're going to bridge Slack and Matrix. How many people are using Matrix? A few. And how many people are in Slack? Yeah. OK. Well, if we make a bridge between the two of those things. We're going to be bridging that. Because the Fedora community is mostly active on the Matrix, which is bridged with IRC. The libera.chat IRC. So we want to really bring together both the Fedora and the OpenShift communities. And so we'll set up a bridge for the Matrix and the Slack channel as soon as we figure out how to do that. Cool.