Merge pull request #70651 from openshift-cherrypick-robot/cherry-pick…

…-70585-to-enterprise-4.12 [enterprise-4.12] OBSDOCS-603: Update CLO attributes
openshift · Jan 22, 2024 · eb3812e · eb3812e
2 parents 1d9ddb6 + 46643af
commit eb3812e
Show file tree

Hide file tree

Showing 2 changed files with 6 additions and 5 deletions.
diff --git a/modules/logging-loki-log-access.adoc b/modules/logging-loki-log-access.adoc
@@ -5,13 +5,14 @@
 :_content-type: CONCEPT
 [id="logging-loki-log-access_{context}"]
 = Fine grained access for Loki logs
-In {logging} 5.8 and later, the ClusterLogging Operator does not grant all users access to logs by default.  As an administrator, you need to configure your users access unless the Operator was upgraded and prior configurations are in place. Depending on your configuration and need, you can configure fine grain access to logs using the following:
+
+In {logging} 5.8 and later, the {clo} does not grant all users access to logs by default. As an administrator, you must configure your users' access unless the Operator was upgraded and prior configurations are in place. Depending on your configuration and need, you can configure fine grain access to logs using the following:
 
 * Cluster wide policies
 * Namespace scoped policies
 * Creation of custom admin groups
 
-As an administrator, you need to create the role bindings and cluster role bindings appropriate for your deployment. The ClusterLogging Operator provides the following cluster roles:
+As an administrator, you need to create the role bindings and cluster role bindings appropriate for your deployment. The {clo} provides the following cluster roles:
 
 * `cluster-logging-application-view` grants permission to read application logs.
 * `cluster-logging-infrastructure-view` grants permission to read infrastructure logs.
@@ -71,7 +72,7 @@ subjects:
 
 == Custom admin group access
 
-If you have a large deployment with a number of users who require broader permissions, you can create a custom group using the `adminGroup` field. Users who are members of any group specified in the `adminGroups` field of the LokiStack CR are considered admins. Admin users have access to all application logs in all namespaces, if they also get assigned the `cluster-logging-application-view` role.
+If you have a large deployment with a number of users who require broader permissions, you can create a custom group using the `adminGroup` field. Users who are members of any group specified in the `adminGroups` field of the `LokiStack` CR are considered admins. Admin users have access to all application logs in all namespaces, if they also get assigned the `cluster-logging-application-view` role.
 
 .Example LokiStack CR
 [source,yaml]

diff --git a/modules/logging-release-notes-5-8-0.adoc b/modules/logging-release-notes-5-8-0.adoc
@@ -6,7 +6,7 @@ This release includes link:https://access.redhat.com/errata/RHBA-2023:6139[OpenS
 
 [id="logging-release-notes-5-8-0-deprecation-notice"]
 == Deprecation notice
-In Logging 5.8, Elasticsearch, Fluentd, and Kibana are deprecated and are planned to be removed in Logging 6.0, which is expected to be shipped alongside a future release of {product-title}. Red Hat will provide critical and above CVE bug fixes and support for these components during the current release lifecycle, but these components will no longer receive feature enhancements. The Vector-based collector provided by the Cluster Logging Operator and LokiStack provided by the {loki-op} are the preferred Operators for log collection and storage. We encourage all users to adopt the Vector and Loki log stack, as this will be the stack that will be enhanced going forward.
+In Logging 5.8, Elasticsearch, Fluentd, and Kibana are deprecated and are planned to be removed in Logging 6.0, which is expected to be shipped alongside a future release of {product-title}. Red Hat will provide critical and above CVE bug fixes and support for these components during the current release lifecycle, but these components will no longer receive feature enhancements. The Vector-based collector provided by the {clo} and LokiStack provided by the {loki-op} are the preferred Operators for log collection and storage. We encourage all users to adopt the Vector and Loki log stack, as this will be the stack that will be enhanced going forward.
 
 [id="logging-release-notes-5-8-0-enhancements"]
 == Enhancements
@@ -17,7 +17,7 @@ In Logging 5.8, Elasticsearch, Fluentd, and Kibana are deprecated and are planne
 +
 [IMPORTANT]
 ====
-In order to support multi-cluster log forwarding in additional namespaces other than the `openshift-logging` namespace, you must update the Cluster Logging Operator to watch all namespaces. This functionality is supported by default in new Cluster Logging Operator version 5.8 installations.
+In order to support multi-cluster log forwarding in additional namespaces other than the `openshift-logging` namespace, you must update the {clo} to watch all namespaces. This functionality is supported by default in new {clo} version 5.8 installations.
 ====
 
 * With this update, you can use the flow control or rate limiting mechanism to limit the volume of log data that can be collected or forwarded by dropping excess log records. The input limits prevent poorly-performing containers from overloading the {logging-uc} and the output limits put a ceiling on the rate of logs shipped to a given data store. (link:https://issues.redhat.com/browse/LOG-884[LOG-884])