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

:_mod-docs-content-type: CONCEPT
[id="mco-update-process_{context}"]
= Understanding how the Machine Config Operator updates nodes

[role="_abstract"]
The Machine Config Operator (MCO) applies a new machine configuration to each control plane node and compute node. During the machine configuration update, control plane nodes and compute nodes are organized into their own machine config pools, where the pools of machines are updated in parallel.

The `.spec.maxUnavailable` parameter, which has a default value of `1`, determines how many nodes in a machine config pool can simultaneously undergo the update process.

[WARNING]
====
The default setting for `maxUnavailable` is `1` for all the machine config pools in {product-title}. It is recommended to not change this value and update one control plane node at a time. Do not change this value to `3` for the control plane pool.
====

When the machine configuration update process begins, the MCO checks the amount of currently unavailable nodes in a pool. If there are fewer unavailable nodes than the value of `.spec.maxUnavailable`, the MCO initiates the following sequence of actions on available nodes in the pool:

. Cordon and drain the node
+
[NOTE]
====
When a node is cordoned, workloads cannot be scheduled to it.
====

. Update the system configuration and operating system (OS) of the node

. Reboot the node

. Uncordon the node

A node undergoing this process is unavailable until it is uncordoned and workloads can be scheduled to it again. The MCO begins updating nodes until the number of unavailable nodes is equal to the value of `.spec.maxUnavailable`.

As a node completes its update and becomes available, the number of unavailable nodes in the machine config pool is once again fewer than `.spec.maxUnavailable`. If there are remaining nodes that need to be updated, the MCO initiates the update process on a node until the `.spec.maxUnavailable` limit is once again reached. This process repeats until each control plane node and compute node has been updated.

The following example workflow describes how this process might occur in a machine config pool with 5 nodes, where `.spec.maxUnavailable` is 3 and all nodes are initially available:

. The MCO cordons nodes 1, 2, and 3, and begins to drain them.

. Node 2 finishes draining, reboots, and becomes available again. The MCO cordons node 4 and begins draining it.

. Node 1 finishes draining, reboots, and becomes available again. The MCO cordons node 5 and begins draining it.

. Node 3 finishes draining, reboots, and becomes available again.

. Node 5 finishes draining, reboots, and becomes available again.

. Node 4 finishes draining, reboots, and becomes available again.

Because the update process for each node is independent of other nodes, some nodes in the example above finish their update out of the order in which they were cordoned by the MCO.

You can check the status of the machine configuration update by running the following command:

[source,terminal]
----
$ oc get mcp
----

.Example output

[source,terminal]
----
NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master       rendered-master-acd1358917e9f98cbdb599aea622d78b       True      False      False      3              3                   3                     0                      22h
worker       rendered-worker-1d871ac76e1951d32b2fe92369879826       False     True       False      2              1                   1                     0                      22h
----
