$ oc edit ClusterLogging instance
In order to modify certain components managed by the Cluster Logging Operator or the Elasticsearch Operator, you must set the operator to the unmanaged state.
In unmanaged state, the operators do not respond to changes in the CRs. The administrator assumes full control of individual component configurations and upgrades when in unmanaged state.
Operators in an unmanaged state are unsupported and the cluster administrator assumes full control of the individual component configurations and upgrades. For more information, see Support policy for unmanaged Operators. |
In managed state, the Cluster Logging Operator (CLO) responds to changes in the Cluster Logging Custom Resource (CR) and adjusts the logging deployment accordingly.
The OpenShift Container Platform documentation indicates in a prerequisite step when you must set the OpenShift Container Platform cluster to Unmanaged.
If you set the Elasticsearch Operator (EO) to unmanaged and leave the Cluster Logging Operator (CLO) as managed, the CLO will revert changes you make to the EO, as the EO is managed by the CLO. |
You must set the operator to the unmanaged state in order to modify the components managed by the Cluster Logging Operator:
the Curator CronJob,
the Elasticsearch CR,
the Kibana Deployment,
the log collector DaemonSet.
If you make changes to these components in managed state, the Cluster Logging Operator reverts those changes.
An unmanaged cluster logging environment does not receive updates until you return the Cluster Logging Operator to Managed state. |
The Cluster Logging Operator must be installed.
Edit the Cluster Logging Custom Resource (CR) in the openshift-logging
project:
$ oc edit ClusterLogging instance
$ oc edit ClusterLogging instance
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
name: "instance"
....
spec:
managementState: "Managed" (1)
1 | Specify the management state as Managed or Unmanaged . |
You must set the operator to the unmanaged state in order to modify the Elasticsearch deployment files, which are managed by the Elasticsearch Operator.
If you make changes to these components in managed state, the Elasticsearch Operator reverts those changes.
An unmanaged Elasticsearch cluster does not receive updates until you return the Elasticsearch Operator to Managed state. |
The Elasticsearch Operator must be installed.
Have the name of the Elasticsearch CR, in the openshift-logging
project:
$ oc get -n openshift-logging Elasticsearch NAME AGE elasticsearch 28h
Edit the Elasticsearch Custom Resource (CR) in the openshift-logging
project:
$ oc edit Elasticsearch elasticsearch
apiVersion: logging.openshift.io/v1
kind: Elasticsearch
metadata:
name: elasticsearch
....
spec:
managementState: "Managed" (1)
1 | Specify the management state as Managed or Unmanaged . |
If you set the Elasticsearch Operator (EO) to unmanaged and leave the Cluster Logging Operator (CLO) as managed, the CLO will revert changes you make to the EO, as the EO is managed by the CLO. |