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
* xref:../../applications/connecting_applications_to_services/understanding-service-binding-operator.adoc#understanding-service-binding-operator[Understanding Service Binding Operator].
70
+
* xref:../../applications/connecting_applications_to_services/understanding-service-binding-operator.adoc#understanding-service-binding-operator[Understanding Service Binding Operator].
Copy file name to clipboardExpand all lines: modules/architecture-machine-roles.adoc
+3-3
Original file line number
Diff line number
Diff line change
@@ -13,9 +13,9 @@ The cluster also contains the definition for the bootstrap role. Because the boo
13
13
14
14
== Control plane and node host compatibility
15
15
16
-
The {product-title} version must match between control plane host and node host. For example, in a 4.10 cluster, all control plane hosts must be 4.10 and all nodes must be 4.10.
16
+
The {product-title} version must match between control plane host and node host. For example, in a 4.11 cluster, all control plane hosts must be 4.11 and all nodes must be 4.11.
17
17
18
-
Temporary mismatches during cluster upgrades are acceptable. For example, when upgrading from {product-title} 4.9 to 4.10, some nodes will upgrade to 4.10 before others. Prolonged skewing of control plane hosts and node hosts might expose older compute machines to bugs and missing features. Users should resolve skewed control plane hosts and node hosts as soon as possible.
18
+
Temporary mismatches during cluster upgrades are acceptable. For example, when upgrading from {product-title} 4.10 to 4.11, some nodes will upgrade to 4.11 before others. Prolonged skewing of control plane hosts and node hosts might expose older compute machines to bugs and missing features. Users should resolve skewed control plane hosts and node hosts as soon as possible.
19
19
20
20
The `kubelet` service must not be newer than `kube-apiserver`, and can be up to two minor versions older depending on whether your {product-title} version is odd or even. The table below shows the appropriate version compatibility:
21
21
@@ -33,7 +33,7 @@ The `kubelet` service must not be newer than `kube-apiserver`, and can be up to
33
33
|===
34
34
[.small]
35
35
--
36
-
1. For example, {product-title} 4.5, 4.7, 4.9.
36
+
1. For example, {product-title} 4.5, 4.7, 4.9, 4.11.
Copy file name to clipboardExpand all lines: modules/eco-node-maintenance-operator-installation-cli.adoc
+5-5
Original file line number
Diff line number
Diff line change
@@ -7,9 +7,9 @@
7
7
= Installing the Node Maintenance Operator by using the CLI
8
8
You can use the OpenShift CLI (`oc`) to install the Node Maintenance Operator.
9
9
10
-
You can install the Node Maintenance Operator in your own namespace or in the `openshift-operators` namespace.
10
+
You can install the Node Maintenance Operator in your own namespace or in the `openshift-operators` namespace.
11
11
12
-
To install the Operator in your own namespace, follow the steps in the procedure.
12
+
To install the Operator in your own namespace, follow the steps in the procedure.
13
13
14
14
To install the Operator in the `openshift-operators` namespace, skip to step 3 of the procedure because the steps to create a new `Namespace` custom resource (CR) and an `OperatorGroup` CR are not required.
15
15
@@ -71,10 +71,10 @@ spec:
71
71
name: node-maintenance-operator
72
72
source: redhat-operators
73
73
sourceNamespace: openshift-marketplace
74
-
StartingCSV: node-maintenance-operator.v4.10.0
74
+
StartingCSV: node-maintenance-operator.v4.11.0
75
75
----
76
76
+
77
-
<1> Specify the `Namespace` where you want to install the Node Maintenance Operator.
77
+
<1> Specify the `Namespace` where you want to install the Node Maintenance Operator.
78
78
+
79
79
[IMPORTANT]
80
80
====
@@ -102,7 +102,7 @@ $ oc get csv -n openshift-operators
Copy file name to clipboardExpand all lines: modules/eco-poison-pill-operator-about.adoc
+2-2
Original file line number
Diff line number
Diff line change
@@ -42,7 +42,7 @@ spec:
42
42
<1> Specify the timeout duration for the surviving peer, after which the Operator can assume that an unhealthy node has been rebooted. The Operator automatically calculates the lower limit for this value. However, if different nodes have different watchdog timeouts, you must change this value to a higher value.
43
43
<2> Specify the file path of the watchdog device in the nodes. If you enter an incorrect path to the watchdog device, the Poison Pill Operator automatically detects the softdog device path.
44
44
+
45
-
If a watchdog device is unavailable, the `PoisonPillConfig` CR uses a software reboot.
45
+
If a watchdog device is unavailable, the `PoisonPillConfig` CR uses a software reboot.
46
46
<3> Specify if you want to enable software reboot of the unhealthy nodes. By default, the value of `isSoftwareRebootEnabled` is set to `true`. To disable the software reboot, set the parameter value to `false`.
47
47
<4> Specify the timeout duration to check connectivity with each API server. When this duration elapses, the Operator starts remediation.
48
48
<5> Specify the frequency to check connectivity with each API server.
@@ -58,7 +58,7 @@ If a watchdog device is unavailable, the `PoisonPillConfig` CR uses a software r
58
58
The Poison Pill Operator also creates the `PoisonPillRemediationTemplate` CR with the name `poison-pill-default-template` in the Poison Pill Operator's namespace. This CR defines the remediation strategy for the nodes.
59
59
60
60
The default remediation strategy is `NodeDeletion` that removes the `node` object.
61
-
In {product-title} 4.10, the Poison Pill Operator introduces a new remediation strategy called `ResourceDeletion`. The `ResourceDeletion` remediation strategy removes the pods and associated volume attachments on the node rather than the `node` object. This strategy helps to recover workloads faster.
61
+
In {product-title} 4.10, the Poison Pill Operator introduced a new remediation strategy called `ResourceDeletion`. The `ResourceDeletion` remediation strategy removes the pods and associated volume attachments on the node rather than the `node` object. This strategy helps to recover workloads faster.
62
62
63
63
The `PoisonPillRemediationTemplate` CR resembles the following YAML file:
0 commit comments