<commit_before>// Module included in the following assemblies:
//
// * architecture/architecture-installation.adoc
// * architecture/control-plane.adoc
// * updating/updating-cluster-between-minor.adoc
// * updating/updating-cluster-cli.adoc
// * updating/updating-cluster-rhel-compute.adoc
// * updating/updating-cluster.adoc
// * updating/updating-disconnected-cluster.adoc

[id="update-service-overview_{context}"]
= About the OpenShift Update Service

The OpenShift Update Service (OSUS) provides over-the-air updates to {product-title}, including {op-system-first}. It provides a graph, or diagram, that contains the _vertices_ of component Operators and the _edges_ that connect them. The edges in the graph show which versions you can safely update to. The vertices are update payloads that specify the intended state of the managed cluster components.

The Cluster Version Operator (CVO) in your cluster checks with the OpenShift Update Service to see the valid updates and update paths based on current component versions and information in the graph. When you request an update, the CVO uses the release image for that update to upgrade your cluster. The release artifacts are hosted in Quay as container images.
////
By accepting automatic updates, you can automatically
keep your cluster up to date with the most recent compatible components.
////

To allow the OpenShift Update Service to provide only compatible updates, a release verification pipeline drives automation. Each release artifact is verified for compatibility with supported cloud platforms and system architectures, as well as other component packages. After the pipeline confirms the suitability of a release, the OpenShift Update Service notifies you that it is available.

[IMPORTANT]
====
The OpenShift Update Service displays all valid updates. Do not force an update to a version that the OpenShift Update Service does not display.
====

////
The interaction between the registry and the OpenShift Update Service is different during bootstrap and continuous update modes. When you bootstrap the initial infrastructure, the Cluster Version Operator finds the fully qualified image name for the shortname of the images that it needs to apply to the server during installation. It looks at the imagestream that it needs to apply and renders it to disk. It calls bootkube and waits for a temporary minimal control plane to come up and load the Cluster Version Operator.
////

Two controllers run during continuous update mode. The first controller continuously updates the payload manifests, applies the manifests to the cluster, and outputs the controlled rollout status of the Operators to indicate whether they are available, upgrading, or failed. The second controller polls the OpenShift Update Service to determine if updates are available.

[IMPORTANT]
====
Only upgrading to a newer version is supported. Reverting or rolling back your cluster to a previous version is not supported. If your upgrade fails, contact Red Hat support.
====

During the upgrade process, the Machine Config Operator (MCO) applies the new configuration to your cluster machines. The MCO cordons the number of nodes as specified by the `maxUnavailable` field on the machine configuration pool and marks them as unavailable. By default, this value is set to `1`. The MCO then applies the new configuration and reboots the machine.
<commit_msg>Add additional explanation why an upgrade is not available in the upgrade service<commit_after>// Module included in the following assemblies:
//
// * architecture/architecture-installation.adoc
// * architecture/control-plane.adoc
// * updating/updating-cluster-between-minor.adoc
// * updating/updating-cluster-cli.adoc
// * updating/updating-cluster-rhel-compute.adoc
// * updating/updating-cluster.adoc
// * updating/updating-disconnected-cluster.adoc

[id="update-service-overview_{context}"]
= About the OpenShift Update Service

The OpenShift Update Service (OSUS) provides over-the-air updates to {product-title}, including {op-system-first}. It provides a graph, or diagram, that contains the _vertices_ of component Operators and the _edges_ that connect them. The edges in the graph show which versions you can safely update to. The vertices are update payloads that specify the intended state of the managed cluster components.

The Cluster Version Operator (CVO) in your cluster checks with the OpenShift Update Service to see the valid updates and update paths based on current component versions and information in the graph. When you request an update, the CVO uses the release image for that update to upgrade your cluster. The release artifacts are hosted in Quay as container images.
////
By accepting automatic updates, you can automatically
keep your cluster up to date with the most recent compatible components.
////

To allow the OpenShift Update Service to provide only compatible updates, a release verification pipeline drives automation. Each release artifact is verified for compatibility with supported cloud platforms and system architectures, as well as other component packages. After the pipeline confirms the suitability of a release, the OpenShift Update Service notifies you that it is available.

[IMPORTANT]
====
The OpenShift Update Service displays all recommended updates for your current cluster.  If an upgrade path is not recommended by the OpenShift Update Service, it might be because of a known issue with the update or the target release.
====

////
The interaction between the registry and the OpenShift Update Service is different during bootstrap and continuous update modes. When you bootstrap the initial infrastructure, the Cluster Version Operator finds the fully qualified image name for the shortname of the images that it needs to apply to the server during installation. It looks at the imagestream that it needs to apply and renders it to disk. It calls bootkube and waits for a temporary minimal control plane to come up and load the Cluster Version Operator.
////

Two controllers run during continuous update mode. The first controller continuously updates the payload manifests, applies the manifests to the cluster, and outputs the controlled rollout status of the Operators to indicate whether they are available, upgrading, or failed. The second controller polls the OpenShift Update Service to determine if updates are available.

[IMPORTANT]
====
Only upgrading to a newer version is supported. Reverting or rolling back your cluster to a previous version is not supported. If your upgrade fails, contact Red Hat support.
====

During the upgrade process, the Machine Config Operator (MCO) applies the new configuration to your cluster machines. The MCO cordons the number of nodes as specified by the `maxUnavailable` field on the machine configuration pool and marks them as unavailable. By default, this value is set to `1`. The MCO then applies the new configuration and reboots the machine.

{'fraction_non_alphanumeric': 0.04718198766671447, 'fraction_numerical': 0.000286820593718629, 'mean_word_length': 4.730484798685292, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '913354', 'n_tokens_mistral': 1552, 'n_tokens_neox': 1473, 'n_words': 959}