// Module included in the following assemblies:
//
// * updating/understanding_updates/how-updates-work.adoc

:_mod-docs-content-type: CONCEPT
[id="update-process-workflow_{context}"]
= Update process workflow

The following steps represent a detailed workflow of the {product-title} (OCP) update process:

. The target version is stored in the `spec.desiredUpdate.version` field of the `ClusterVersion` resource, which may be managed through the web console or the CLI.

. The Cluster Version Operator (CVO) detects that the `desiredUpdate` in the `ClusterVersion` resource differs from the current cluster version.
Using graph data from the OpenShift Update Service, the CVO resolves the desired cluster version to a pull spec for the release image.

. The CVO validates the integrity and authenticity of the release image.
Red Hat publishes cryptographically-signed statements about published release images at predefined locations by using image SHA digests as unique and immutable release image identifiers.
The CVO utilizes a list of built-in public keys to validate the presence and signatures of the statement matching the checked release image.

. The CVO creates a job named `version-$version-$hash` in the `openshift-cluster-version` namespace.
This job uses containers that are executing the release image, so the cluster downloads the image through the container runtime.
The job then extracts the manifests and metadata from the release image to a shared volume that is accessible to the CVO.

. The CVO validates the extracted manifests and metadata.

. The CVO checks some preconditions to ensure that no problematic condition is detected in the cluster.
Certain conditions can prevent updates from proceeding.
These conditions are either determined by the CVO itself, or reported by individual cluster Operators that detect some details about the cluster that the Operator considers problematic for the update.

. The CVO records the accepted release in `status.desired` and creates a `status.history` entry about the new update.

. The CVO begins reconciling the manifests from the release image.
Cluster Operators are updated in separate stages called Runlevels, and the CVO ensures that all Operators in a Runlevel finish updating before it proceeds to the next level.

. Manifests for the CVO itself are applied early in the process.
When the CVO deployment is applied, the current CVO pod stops, and a CVO pod that uses the new version starts.
The new CVO proceeds to reconcile the remaining manifests.

. The update proceeds until the entire control plane is updated to the new version.
Individual cluster Operators might perform update tasks on their domain of the cluster, and while they do so, they report their state through the `Progressing=True` condition.

. The Machine Config Operator (MCO) manifests are applied towards the end of the process.
The updated MCO then begins updating the system configuration and operating system of every node.
Each node might be drained, updated, and rebooted before it starts to accept workloads again.

The cluster reports as updated after the control plane update is finished, usually before all nodes are updated.
After the update, the CVO maintains all cluster resources to match the state delivered in the release image.
