Merge pull request #21630 from openshift-cherrypick-robot/cherry-pick-21553-to-enterprise-4.4

[enterprise-4.4] Add Unmanaged Operators support statement

architecture/architecture-installation.adoc

@@ -6,4 +6,6 @@ toc::[]
 
 include::modules/installation-overview.adoc[leveloffset=+1]
 
-include::modules/update-service-overview.adoc[leveloffset=+1]
+include::modules/update-service-overview.adoc[leveloffset=+1]
+
+include::modules/unmanaged-operators.adoc[leveloffset=+1]

modules/unmanaged-operators.adoc

@@ -0,0 +1,56 @@
+// Module included in the following assemblies:
+//
+// * architecture/architecture-installation.adoc
+// * updating/updating-cluster-between-minor.adoc
+
+[id="unmanaged-operators_{context}"]
+= Support policy for unmanaged Operators
+
+The _management state_ of an Operator determines whether an Operator is actively
+managing the resources for its related component in the cluster as designed. If
+an Operator is set to an _unmanaged_ state, it does not respond to changes in
+configuration nor does it receive updates.
+
+While this can be helpful in non-production clusters or during debugging,
+Operators in an unmanaged state are unsupported and the cluster administrator
+assumes full control of the individual component configurations and upgrades.
+
+An Operator can be set to an unmanaged state using the following methods:
+
+* **Individual Operator configuration**
++
+Individual Operators have a `managementState` parameter in their configuration.
+This can be accessed in different ways, depending on the Operator. For example,
+the Cluster Logging Operator accomplishes this by modifying a Custom Resource
+(CR) that it manages, while the Samples Operator uses a cluster-wide
+configuration resource.
++
+Changing the `managementState` parameter to `Unmanaged` means that the Operator
+is not actively managing its resources and will take no action related to the
+related component. Some Operators might not support this management state as it
+might damage the cluster and require manual recovery.
++
+[WARNING]
+====
+Changing individual Operators to the `Unmanaged` state renders that particular
+component and functionality unsupported. Reported issues must be reproduced in
+`Managed` state for support to proceed.
+====
+
+* **Cluster Version Operator (CVO) overrides**
++
+The `spec.overrides` parameter can be added to the CVO's configuration to allow
+administrators to provide a list of overrides to the CVO's behavior for a
+component. Setting the `spec.overrides[].unmanaged` parameter to `true` for a
+component blocks cluster upgrades and alerts the administrator after a CVO
+override has been set:
++
+----
+Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.
+----
++
+[WARNING]
+====
+Setting a CVO override puts the entire cluster in an unsupported state. Reported
+issues must be reproduced after removing any overrides for support to proceed.
+====

modules/update-service-overview.adoc

@@ -1,9 +1,12 @@
 // Module included in the following assemblies:
 //
 // * architecture/architecture-installation.adoc
+// * architecture/control-plane.adoc
+// * updating/updating-cluster-between-minor.adoc
 // * updating/updating-cluster-cli.adoc
 // * updating/updating-cluster-rhel-compute.adoc
 // * updating/updating-cluster.adoc
+// * updating/updating-disconnected-cluster.adoc
 
 [id="update-service-overview_{context}"]
 = About the {product-title} update service

updating/updating-cluster-between-minor.adoc

@@ -29,6 +29,9 @@ After this one-time manual restart, subsequent upgrades and rotations will ensur
 ====
 
 include::modules/update-service-overview.adoc[leveloffset=+1]
+.Additional resources
+
+* xref:../architecture/architecture-installation.adoc#unmanaged-operators_architecture-installation[Support policy for unmanaged Operators]
 
 include::modules/understanding-upgrade-channels.adoc[leveloffset=+1]
 

updating/updating-cluster-cli.adoc

@@ -14,6 +14,9 @@ See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permis
 * Have a recent xref:../backup_and_restore/backing-up-etcd.adoc#backup-etcd[etcd backup] in case your upgrade fails and you must xref:../backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[restore your cluster to a previous state].
 
 include::modules/update-service-overview.adoc[leveloffset=+1]
+.Additional resources
+
+* xref:../architecture/architecture-installation.adoc#unmanaged-operators_architecture-installation[Support policy for unmanaged Operators]
 
 include::modules/understanding-upgrade-channels.adoc[leveloffset=+1]
 

updating/updating-cluster-rhel-compute.adoc

@@ -26,6 +26,9 @@ After this one-time manual restart, subsequent upgrades and rotations will ensur
 ====
 
 include::modules/update-service-overview.adoc[leveloffset=+1]
+.Additional resources
+
+* xref:../architecture/architecture-installation.adoc#unmanaged-operators_architecture-installation[Support policy for unmanaged Operators]
 
 include::modules/understanding-upgrade-channels.adoc[leveloffset=+1]
 

updating/updating-cluster.adoc

@@ -14,6 +14,9 @@ See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permis
 * Have a recent xref:../backup_and_restore/backing-up-etcd.adoc#backup-etcd[etcd backup] in case your upgrade fails and you must xref:../backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[restore your cluster to a previous state].
 
 include::modules/update-service-overview.adoc[leveloffset=+1]
+.Additional resources
+
+* xref:../architecture/architecture-installation.adoc#unmanaged-operators_architecture-installation[Support policy for unmanaged Operators]
 
 include::modules/understanding-upgrade-channels.adoc[leveloffset=+1]