You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/user/reconciliation.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -93,22 +93,22 @@ So the graph nodes are all parallelized with the by-number ordering flattened ou
93
93
94
94
For the usual reconciliation loop (neither an upgrade between releases nor a fresh install), the flattened graph is also randomly permuted to avoid hanging on ordering bugs.
95
95
96
-
## Synchronizing the graph
96
+
## Reconciling the graph
97
97
98
98
The cluster-version operator spawns worker goroutines that walk the graph, pushing manifests in their queue.
99
-
For each manifest in the node, the worker synchronizes the cluster with the manifest using a resource builder.
99
+
For each manifest in the node, the worker reconciles the cluster with the manifest using a resource builder.
100
100
On error (or timeout), the worker abandons the manifest, graph node, and any dependencies of that graph node.
101
101
On success, the worker proceeds to the next manifest in the graph node.
102
102
103
103
## Resource builders
104
104
105
-
Resource builders synchronize the cluster with a manifest from the release image.
105
+
Resource builders reconcile a cluster object with a manifest from the release image.
106
106
The general approach is to generates a merged manifest combining critical spec properties from the release-image manifest with data from a preexisting in-cluster object, if any.
107
107
If the merged manifest differs from the in-cluster object, the merged manifest is pushed back into the cluster.
108
108
109
109
Some types have additional logic, as described in the following subsections.
110
110
Note that this logic only applies to manifests included in the release image itself.
111
-
For example, only [ClusterOperator](../dev/clusteroperator.md) from the release image will have the blocking logic described [below](#clusteroperator); if an admin or secondary operator pushed a ClusterOperator object, it would not impact the cluster-version operator's graph synchronization.
111
+
For example, only [ClusterOperator](../dev/clusteroperator.md) from the release image will have the blocking logic described [below](#clusteroperator); if an admin or secondary operator pushed a ClusterOperator object, it would not impact the cluster-version operator's graph reconciliation.
Copy file name to clipboardExpand all lines: docs/user/status.md
+22Lines changed: 22 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,6 +3,27 @@
3
3
[The ClusterVersion object](../dev/clusterversion.md) sets `conditions` describing the state of the cluster-version operator (CVO).
4
4
This document describes those conditions and, where appropriate, suggests possible mitigations.
5
5
6
+
## Failing
7
+
8
+
When `Failing` is True, the CVO is failing to reconcile the cluster with the desired release image.
9
+
In all cases, the impact on the cluster will be that dependent nodes in [the manifest graph](reconciliation.md#manifest-graph) may not be [reconciled](reconciliation.md#reconciling-the-graph).
10
+
Note that the graph [may be flattened](reconciliation.md#manifest-graph), in which case there are no dependent nodes.
11
+
12
+
Most reconciliation errors will result in `Failing=True`, although [`ClusterOperatorNotAvailable`](#clusteroperatornotavailable) has special handling.
13
+
14
+
### NoDesiredImage
15
+
16
+
The CVO has not been given a release image to reconcile.
17
+
18
+
If this happens it is a CVO coding error, because clearing [`desiredUpdate`][api-desired-update] should return you to the current CVO's release image.
19
+
20
+
### ClusterOperatorNotAvailable
21
+
22
+
`ClusterOperatorNotAvailable` (or the consolidated `ClusterOperatorsNotAvailable`) is set when the CVO fails to retrieve the ClusterOperator from the cluster or when the retrieved ClusterOperator does not satisfy [the reconciliation conditions](reconciliation.md#clusteroperator).
23
+
24
+
Unlike most manifest-reconciliation failures, this error does not immediately result in `Failing=True`.
25
+
Under some conditions during installs and updates, the CVO will treat this condition as a `Progressing=True` condition and give the operator up to ten minutes to level before reporting `Failing=True`.
26
+
6
27
## RetrievedUpdates
7
28
8
29
When `RetrievedUpdates` is `True`, the CVO is succesfully retrieving updates, which is good.
@@ -107,5 +128,6 @@ If this error occurs because you forced an update to a release that is not in an
107
128
If this happens it is a CVO coding error.
108
129
There is no mitigation short of updating to a new release image with a fixed CVO.
0 commit comments