 Hello, welcome back to OpenShift 4.x deep dive video series. In this video, we'll talk about over-the-air update process for your cluster. And we'll also see how the application operators updates happen through the operator lifecycle manager. Over-the-air upgrades to your cluster can be performed either using OpenShift Administrative Console or you can also use Red Hat Cloud Web Interface. Red Hat runs an OCP update service through which it provides over-the-air updates for Red Hat couriers and OpenShift. The release artifacts are packaged as container images so you don't require any other mechanism to deliver updates. These images contain the controller manifest, roles, and other resources required to update your cluster to a particular version. OpenShift 4.x runs a cluster version operator on each cluster and this operator pulls for any available updates from the over-the-air update service hosted by Red Hat. If the updates are available, it goes ahead and downloads the release images for the update. So if you go to your running cluster and navigate to the administration section and look at the cluster settings, if there are any updates available, it will tell you here this is because your cluster version operator would have checked with the OTA service and knows that there is an update. So on my cluster, it shows clearly that the update is available. If I click on this update now, it says that my current version is 4.3.8 and the 4.3.9 is available and I can click on this update and this will start performing the update. So the cluster version operator downloads the release image for the update and it manages the updates to all the cluster operators. So in the past, we discussed the difference between the two types of operators. One of them is the cluster operators or the platform operators make up your cluster and the other set of operators are application kind of operators that are managed by the OLM. Here, we are only talking about the cluster or platform operators that are updated based on this cluster version operator and these include things like authentication storage registry, EFK stack and things like that. It updates all these operators running on your cluster in the right order. Eventually your cluster gets updated. Now, let us talk about the application operator upgrades, the ones that are managed by the operator lifecycle manager. So these are the third party applications or your own applications that are exposed via the operator hub and if you install any of those operators, how do these operators get updated? So each one has a cluster service version and these cluster service versions for operators are stored in a catalog source. Within a catalog source, the operators are organized into packages called channels. On my cluster, we have a bunch of catalog sources and my operators installed via OLM are organized into one of these catalog sources. We'll look at one of the operators that is installed. I'm looking at the open shift serverless operator. When you look at the subscription for this operator, this is coming from a catalog source red hat operators and it is part of tick preview channel. I also note that the approval for this operator is set to automatic. I can change this from automatic to manual, in which case it will not automatically apply any updates. Now, every catalog source is associated with an operator source which provides the endpoint to inquire for any updates from the registry where this operators are published. Currently the updates to operators are published on quay.io. Let us look at the operator sources. So you can see that there are three different operator sources. We are interested in the red hat operators. You can see that red hat operators are coming from a registry which is quay.io slash CNR and this is the endpoint where the catalog source will fall for any updates. Now, let us describe this operator source for red hat operators. It shows the list of packages that the operator source provides and it also shows when the last reconciliation was done. So updates to the OLM managed operators are handled by the catalog sources by directly polling with quay.io and the subscriptions are updated on the cluster based on whether they are set to update manually or set for automatic updates. So to summarize in this video, we discussed how over the air updates to your cluster work and we also discussed how application operators are updated. I hope you enjoyed this video. Thanks a lot for watching.