Merge pull request #69346 from skopacz1/update_list_order

Author: sheriff-rh

modules/update-process-workflow.adoc

@@ -27,19 +27,15 @@ The job then extracts the manifests and metadata from the release image to a sha
 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.
 
-// to do: potentially add an example of a precondition to the bullet above.
-
 . 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 terminates, and a CVO pod using the new version starts.
+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.
 
-// to do: potentially replace some instances of "apply" in this doc with something like "reconcile" to imply that a lot of these processes are constantly repeating, rather than happening only once.
-
 . 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.