mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 21:46:22 +01:00
Fixing list order in how updates work doc
This commit is contained in:
@@ -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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user