Merge pull request #45783 from opayne1/OSDOCS-3584

OSDOCS-3584: partial cluster update docs

Author: jeana-redhat

updating/preparing-eus-eus-upgrade.adoc

@@ -14,6 +14,7 @@ There are a number of caveats to consider when attempting an EUS-to-EUS update.
 
 * EUS-to-EUS updates are only offered after updates between all versions involved have been made available in `stable` channels.
 * If you encounter issues during or after upgrading to the odd-numbered minor version but before upgrading to the next even-numbered version, then remediation of those issues may require that non-master hosts complete the update to the odd-numbered version before moving forward.
+* You can do a partial update by updating the worker or custom pool nodes to accommodate the time it takes for maintenance. 
 * You can complete the update process during multiple maintenance windows by pausing at intermediate steps. However, plan to complete the entire update within 60 days. This is critical to ensure that normal cluster automation processes are completed including those associated with certificate rotation.
 * You must be running at least {product-title} 4.8.14 before starting the EUS-to-EUS update procedure. If you do not meet this minimum requirement, update to a later 4.8.z before attempting the EUS-to-EUS update.
 * Support for RHEL7 workers was removed in {product-title} 4.10 and replaced with RHEL8 workers, therefore EUS-to-EUS updates are not available for clusters with RHEL7 workers.

updating/updating-cluster-within-minor.adoc

@@ -21,6 +21,8 @@ See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permis
 * Support for {op-system-base}7 workers is removed in {product-title} {product-version}. You must replace {op-system-base}7 workers with {op-system-base}8 or {op-system} workers before upgrading to {product-title} {product-version}. Red Hat does not support in-place {op-system-base}7 to {op-system-base}8 upgrades for {op-system-base} workers; those hosts must be replaced with a clean operating system install.
 * Ensure all Operators previously installed through Operator Lifecycle Manager (OLM) are updated to their latest version in their latest channel. Updating the Operators ensures they have a valid update path when the default OperatorHub catalogs switch from the current minor version to the next during a cluster update. See xref:../operators/admin/olm-upgrading-operators.adoc#olm-upgrading-operators[Upgrading installed Operators] for more information.
 * Ensure that all machine config pools (MCPs) are running and not paused. Nodes associated with a paused MCP are skipped during the update process. You can pause the MCPs if you are performing a canary rollout update strategy.
+//remove this???^ or maybe just add another bullet that you can break up the update?
+* To accommodate the time it takes to update, you are able to do a partial update by updating the worker or custom pool nodes. You can pause and resume within the progress bar of each pool. 
 * If your cluster uses manually maintained credentials, ensure that the Cloud Credential Operator (CCO) is in an upgradeable state. For more information, see xref:../updating/updating-cluster-cli.adoc#manually-maintained-credentials-upgrade_updating-cluster-cli[Upgrading clusters with manually maintained credentials].
 * If your cluster uses manually maintained credentials with the AWS Secure Token Service (STS), obtain a copy of the `ccoctl` utility from the release image being updated to and use it to process any updated credentials. For more information, see xref:../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#sts-mode-upgrading[Upgrading an OpenShift Container Platform cluster configured for manual mode with STS].