 All right, well, next up, we have Vadim Rotovsky, dialing in from Bruno, and he's going to walk us through the current release process and tell us a little bit about where things live in GitHub. So Vadim, you wanna share your screen and take it away. Hello, my name is Vadim and I work for Redhead and my day job is being an engineer for OpenShift, but in the evening, I like to tinker with Mochiti and other community distributions. So today we'll take a guide on about how we can get built, where things happening, where's the source, and why do we need such a complex CI to make it happen? So our final step in the release process is uploading the binaries of Installer and OC to GitHub, but in order to make it happen, we first need to build it from the source code. And as everything else, things are happening in the organization called OpenShift, where the code for both OCP and OQD being created. For those who are not familiar with semi-crimes, OCP stands for OpenShift Container Platform, that's a product which Redhead officially supports, provides a subscription to the clients and OQD is a community distribution, which is related to OCP as well. So let's have a look at one single simple repo, which is called Origin Branding. It contains several simple things. First of all is the Dockerfile because all pieces of OQD and OCP are container images. So this Dockerfile explains how to build it. We're building from scratch. Then we copy the files in the manifest and label this image as an operator. That means as Charo has explained previously, everything in OQD and OCP is based on operators. So we have a top-level operator called Gloucester version operator, which all it does is applies all the pieces to your cluster and they assemble into an OpenShift release. So the manifest we're applying is in fact a simple config map which instructs the console to use OQD branding and set a different base URL. When the OpenShift console is started and it finds this configuration, it applies to OQD branding. And in the help message, you would have a different documentation base URL. So all of those changes we're looking into are built by CI. You can see we get green marks meeting in asbest. And everything is done via the photo quests. For instance, here is the output of our CI. We're using Kubernetes testing for a project called Prow to build, assemble and manage our images created by CI. For instance, here we can see that we're using Origin 4.8 ImageStream as a base because all of the images we make release from are in fact stored in OpenShift itself and they are stored in the form of the ImageStream tags. So we use 4.8 as a base, build branding image, tag it back into the temporary stable ImageStream and we don't run any particular tests because it's just one single config map. And we immediately promote it back to 4.8 ImageStream and we promote just this single part. So that instructs CI to build the image we have submitted, run some tests if they are present. For instance, in other repos who might have additional end-to-end notifications for AWS, same test for AWS, but an upgrade test using previous date and a new release with this image, GCP vSphere and so on and so forth, depending on what kind of repo that is. And once we're done, it would promote it as an official image in the 4.8. So the whole release part is stored as a part of ImageStream in our CI. And once we're done, the CI would also track the ImageStream and would be building new releases out of that, meaning you would be able, it would be able to compile them into one single image which refers to a bunch of other images and fetch some metadata from them. For instance, if we would use OC Adam release info command on some release images, we would be able to extract URLs to each particular commits this image has been built from, as you can see on this picture, for instance. And since CI can do that, so that users can also create their own release payloads based on the payloads we had released already, replacing some particular images with the fixes they would like to test or some changes they would like to have performed. Another important part in this is that OKD is sharing a lot of images with OCB itself, meaning using the project called Red Hat Universal Base image, we are now able to officially release images which are built on the Red Hat Enterprise Linux. Back in three 11 days, OKD used to be based on top of CentOS, but now we can use the very same image based on UBI and that very same image can be used simultaneously in OKD in OCB without any branding or legal problems. And that allows us CI to stop doing duplicate work. And once the commit lands in the branch, we are able to build an image promoted to OCB and at the same time promoted to OKD. For instance, this script would show us that coordinates image in the latest origin or so-called OKD payload is the same coordinates image as in one of the releases of OCB. We're fetching the pulse back for those image and once we use command OC image info to display information about labels, layers, environment, variables and so on. And if we div the output from this image, the only difference is just name there being pushed. All the rest is the same because these are the same images. Next, the most important part is our release controller page where that's the front end of our CI which detects that when a new release lands in, a new image lands in the image stream, we can prepare a new release. Let's look at something more greenish like this one. It builds the difference between the previous release, shows that two new images have landed. Based on the metadata they contain, we can also build links to the pull request which have caused this change. And so on so forth. And these nightly images can eventually be promoted to stable for instance. This latest 47 release used to be a nightly release with the same date. And in order to perform a stable release we have a small instruction. What to do it basically boils down to mirroring the image to Quay, running some additional tests and tagging it in the state for stable channel. All the rest is done by CI itself which automatically updates the update graph, runs additional tests and we can see that users from the previous releases can upgrade and what's the best result for that. Since the OCD is slightly different from OCD or OCP as it uses different images in some cases, we also have a different issue tracker. We use open shift issues to track OCD specific problems. However, since most of the images we're using from OCP, for instance, console is copied as is from OCP. So any kind of UI issue you're hitting would be reproducible on OCP as well. That means you would file a proper OCP image because you would be sure that it happens for OCP as well and you would get direct developer attention to fix it. And once we're there, we also request you to, let me pick one of my favorite ones. Let's pick the closed. We also ask you to provide a log bundle so-called where a lot of logs from the failed installation or broken cluster itself. That archive should contain all the logs for us to find out what's happening, which part are doing the fix or what's missing. And after we're done, we're also uploading the client tools to GitHub and send the message to OCD Working Group. So to reiterate in the end, OCD is a community distribution that means all the images we're listing here have their GitHub repos, meaning you can reveal them, think of them, replace some parts and collaborate with us to make it better. We make decisions on the work group calls. Those are recorded by Diane and released to our YouTube channel. OCD 4 is no longer an upstream need stream or downstream of OCD 4. It shares a lot of images with it but still has its own special replaced parts. So we're going to term sibling distributions for this kind of event. And we heavily rely on automation and CI verification and also user feedback when we are releasing OCD. And that concludes my demo. Thank you.