mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
59 lines
2.4 KiB
Plaintext
59 lines
2.4 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * architecture/architecture-installation.adoc
|
|
// * updating/updating-cluster-within-minor.adoc
|
|
// * observability/logging/cluster-logging-support.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 Red Hat OpenShift Logging Operator accomplishes this by modifying a custom resource
|
|
(CR) that it manages, while the Cluster 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:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
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.
|
|
====
|