Merge pull request #70254 from abrennan89/op-attributes

OBDOCS-603: Replace last Loki Operators with attribute

Author: abrennan89

modules/logging-loki-gui-install.adoc

@@ -24,7 +24,7 @@ To install and configure logging on your {product-title} cluster, additional Ope
 +
 [IMPORTANT]
 ====
-The Community Loki Operator is not supported by Red Hat.
+The Community {loki-op} is not supported by Red Hat.
 ====
 
 . Select *stable* or *stable-x.y* as the *Update channel*.

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 Operator 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 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.
 
 [id="logging-release-notes-5-8-0-enhancements"]
 == Enhancements
@@ -30,7 +30,7 @@ In order to support multi-cluster log forwarding in additional namespaces other
 === Log Storage
 * With this update, LokiStack administrators can have more fine-grained control over who can access which logs by granting access to logs on a namespace basis. (link:https://issues.redhat.com/browse/LOG-3841[LOG-3841])
 
-* With this update, the Loki Operator introduces `PodDisruptionBudget` configuration on LokiStack deployments to ensure normal operations during {product-title} cluster restarts by keeping ingestion and the query path available. (link:https://issues.redhat.com/browse/LOG-3839[LOG-3839])
+* With this update, the {loki-op} introduces `PodDisruptionBudget` configuration on LokiStack deployments to ensure normal operations during {product-title} cluster restarts by keeping ingestion and the query path available. (link:https://issues.redhat.com/browse/LOG-3839[LOG-3839])
 
 * With this update, the reliability of existing LokiStack installations are seamlessly improved by applying a set of default Affinity and Anti-Affinity policies.
 (link:https://issues.redhat.com/browse/LOG-3840[LOG-3840])

modules/logging-rn-5.7.3.adoc

@@ -9,13 +9,13 @@ This release includes link:https://access.redhat.com/errata/RHSA-2023:3998[OpenS
 == Bug fixes
 * Before this update, when viewing logs within the {product-title} web console, cached files caused the data to not refresh. With this update the bootstrap files are not cached, resolving the issue. (link:https://issues.redhat.com/browse/LOG-4100[LOG-4100])
 
-* Before this update, the Loki Operator reset errors in a way that made identifying configuration problems difficult to troubleshoot. With this update, errors persist until the configuration error is resolved. (link:https://issues.redhat.com/browse/LOG-4156[LOG-4156])
+* Before this update, the {loki-op} reset errors in a way that made identifying configuration problems difficult to troubleshoot. With this update, errors persist until the configuration error is resolved. (link:https://issues.redhat.com/browse/LOG-4156[LOG-4156])
 
-* Before this update, the LokiStack ruler did not restart after changes were made to the `RulerConfig` custom resource (CR). With this update, the Loki Operator restarts the ruler pods after the `RulerConfig` CR is updated. (link:https://issues.redhat.com/browse/LOG-4161[LOG-4161])
+* Before this update, the LokiStack ruler did not restart after changes were made to the `RulerConfig` custom resource (CR). With this update, the {loki-op} restarts the ruler pods after the `RulerConfig` CR is updated. (link:https://issues.redhat.com/browse/LOG-4161[LOG-4161])
 
 * Before this update, the vector collector terminated unexpectedly when input match label values contained a `/` character within the `ClusterLogForwarder`. This update resolves the issue by quoting the match label, enabling the collector to start and collect logs. (link:https://issues.redhat.com/browse/LOG-4176[LOG-4176])
 
-* Before this update, the Loki Operator terminated unexpectedly when a `LokiStack` CR defined tenant limits, but not global limits. With this update, the Loki Operator can process `LokiStack` CRs without global limits, resolving the issue. (link:https://issues.redhat.com/browse/LOG-4198[LOG-4198])
+* Before this update, the {loki-op} terminated unexpectedly when a `LokiStack` CR defined tenant limits, but not global limits. With this update, the {loki-op} can process `LokiStack` CRs without global limits, resolving the issue. (link:https://issues.redhat.com/browse/LOG-4198[LOG-4198])
 
 * Before this update, Fluentd did not send logs to an Elasticsearch cluster when the private key provided was passphrase-protected. With this update, Fluentd properly handles passphrase-protected private keys when establishing a connection with Elasticsearch. (link:https://issues.redhat.com/browse/LOG-4258[LOG-4258])
 

modules/logging-rn-5.7.4.adoc

@@ -19,7 +19,7 @@ This release includes link:https://access.redhat.com/errata/RHSA-2023:4341[OpenS
 * Before this update, the Vector collector occasionally panicked with the following error message in its log:
 `thread 'vector-worker' panicked at 'all branches are disabled and there is no else branch', src/kubernetes/reflector.rs:26:9`. With this update, the error has been resolved. (link:https://issues.redhat.com/browse/LOG-4275[LOG-4275])
 
-* Before this update, an issue in the Loki Operator caused the `alert-manager` configuration for the application tenant to disappear if the Operator was configured with additional options for that tenant. With this update, the generated Loki configuration now contains both the custom and the auto-generated configuration. (link:https://issues.redhat.com/browse/LOG-4361[LOG-4361])
+* Before this update, an issue in the {loki-op} caused the `alert-manager` configuration for the application tenant to disappear if the Operator was configured with additional options for that tenant. With this update, the generated Loki configuration now contains both the custom and the auto-generated configuration. (link:https://issues.redhat.com/browse/LOG-4361[LOG-4361])
 
 * Before this update, when multiple roles were used to authenticate using STS with AWS Cloudwatch forwarding, a recent update caused the credentials to be non-unique. With this update, multiple combinations of STS roles and static credentials can once again be used to authenticate with AWS Cloudwatch. (link:https://issues.redhat.com/browse/LOG-4368[LOG-4368])
 

modules/logging-upgrading-loki.adoc

@@ -20,7 +20,7 @@ To update the {loki-op} to a new major release version, you must modify the upda
 
 . Select the *openshift-operators-redhat* project.
 
-. Click the *Loki Operator*.
+. Click the *{loki-op}*.
 
 . Click *Subscription*. In the *Subscription details* section, click the *Update channel* link. This link text might be *stable* or *stable-5.y*, depending on your current update channel.
 

modules/network-observability-lokistack-create.adoc

@@ -9,34 +9,34 @@
 You can deploy a LokiStack using the web console or CLI to create a namespace, or new project.
 
 include::snippets/logging-clusteradmin-access-logs-snip.adoc[]
-For more information about creating a `cluster-admin` group, see the "Additional resources" section.  
+For more information about creating a `cluster-admin` group, see the "Additional resources" section.
 
 .Procedure
 
 . Navigate to *Operators* -> *Installed Operators*, viewing *All projects* from the *Project* dropdown.
-. Look for *Loki Operator*. In the details, under *Provided APIs*, select *LokiStack*.
+. Look for *{loki-op}*. In the details, under *Provided APIs*, select *LokiStack*.
 . Click *Create LokiStack*.
 . Ensure the following fields are specified in either *Form View* or *YAML view*:
 +
 [source,yaml]
 ----
-  apiVersion: loki.grafana.com/v1
-  kind: LokiStack
-  metadata:
-    name: loki
-    namespace: netobserv   <1>
-  spec:
-    size: 1x.small
-    storage:
-      schemas:
-      - version: v12
-        effectiveDate: '2022-06-01'
-      secret:
-        name: loki-s3
-        type: s3
-    storageClassName: gp3  <2>
-    tenants:
-      mode: openshift-network
+apiVersion: loki.grafana.com/v1
+kind: LokiStack
+metadata:
+  name: loki
+  namespace: netobserv   <1>
+spec:
+  size: 1x.small
+  storage:
+    schemas:
+    - version: v12
+      effectiveDate: '2022-06-01'
+    secret:
+      name: loki-s3
+      type: s3
+  storageClassName: gp3  <2>
+  tenants:
+    mode: openshift-network
 ----
 <1> The installation examples in this documentation use the same namespace, `netobserv`, across all components. You can optionally use a different namespace.
 <2> Use a storage class name that is available on the cluster for `ReadWriteOnce` access mode. You can use `oc get storageclasses` to see what is available on your cluster.

modules/security-monitoring-cluster-logging.adoc

@@ -5,14 +5,9 @@
 [id="security-monitoring-cluster-logging_{context}"]
 = Logging
 
-Using the `oc log` command, you can view container logs, build configs and
-deployments in real time. Different can users have access different
-access to logs:
+Using the `oc log` command, you can view container logs, build configs and deployments in real time. Different can users have access different access to logs:
 
 * Users who have access to a project are able to see the logs for that project by default.
 * Users with admin roles can access all container logs.
 
-To save your logs for further audit and analysis, you can enable the `cluster-logging` add-on
-feature to collect, manage, and view system, container, and audit logs.
-You can deploy, manage, and upgrade OpenShift Logging through the OpenShift Elasticsearch Operator
-and Red Hat OpenShift Logging Operator.
+To save your logs for further audit and analysis, you can enable the `cluster-logging` add-on feature to collect, manage, and view system, container, and audit logs. You can deploy, manage, and upgrade OpenShift Logging through the {es-op} and {clo}.

modules/troubleshooting-network-observability-loki-tenant-rate-limit.adoc

@@ -11,7 +11,7 @@ You can update the LokiStack CRD with the `perStreamRateLimit` and `perStreamRat
 
 .Procedure
 . Navigate to *Operators* -> *Installed Operators*, viewing *All projects* from the *Project* dropdown.
-. Look for *Loki Operator*, and select the *LokiStack* tab.
+. Look for *{loki-op}*, and select the *LokiStack* tab.
 . Create or edit an existing *LokiStack* instance using the *YAML view* to add the `perStreamRateLimit` and `perStreamRateLimitBurst` specifications:
 +
 [source, yaml]
@@ -37,4 +37,4 @@ spec:
 . Click *Save*.
 
 .Verification
-Once you update the `perStreamRateLimit` and `perStreamRateLimitBurst` specifications, the pods in your cluster restart and the 429 rate-limit error no longer occurs.
+Once you update the `perStreamRateLimit` and `perStreamRateLimitBurst` specifications, the pods in your cluster restart and the 429 rate-limit error no longer occurs.

network_observability/network-observability-operator-release-notes.adoc

@@ -125,7 +125,7 @@ Network Observability Operator can now run on `s390x` architecture. Previously i
 
 [id="network-observability-operator-1.4.0-known-issues"]
 === Known issues
-* Since the 1.2.0 release of the Network Observability Operator, using Loki Operator 5.6, a Loki certificate change periodically affects the `flowlogs-pipeline` pods and results in dropped flows rather than flows written to Loki. The problem self-corrects after some time, but it still causes temporary flow data loss during the Loki certificate change. This issue has only been observed in large-scale environments of 120 nodes or greater. (link:https://issues.redhat.com/browse/NETOBSERV-980[*NETOBSERV-980*])
+* Since the 1.2.0 release of the Network Observability Operator, using {loki-op} 5.6, a Loki certificate change periodically affects the `flowlogs-pipeline` pods and results in dropped flows rather than flows written to Loki. The problem self-corrects after some time, but it still causes temporary flow data loss during the Loki certificate change. This issue has only been observed in large-scale environments of 120 nodes or greater. (link:https://issues.redhat.com/browse/NETOBSERV-980[*NETOBSERV-980*])
 
 * Currently, when `spec.agent.ebpf.features` includes DNSTracking, larger DNS packets require the `eBPF` agent to look for DNS header outside of the 1st socket buffer (SKB) segment. A new `eBPF` agent helper function needs to be implemented to support it. Currently, there is no workaround for this issue. (link:https://issues.redhat.com/browse/NETOBSERV-1304[*NETOBSERV-1304*])
 
@@ -169,7 +169,7 @@ You must switch your channel from `v1.0.x` to `stable` to receive future Operato
 
 [id="authToken-host"]
 ==== Deprecated configuration parameter setting
-The release of Network Observability Operator 1.3 deprecates the `spec.Loki.authToken` `HOST` setting. When using the Loki Operator, you must now only use the `FORWARD` setting.
+The release of Network Observability Operator 1.3 deprecates the `spec.Loki.authToken` `HOST` setting. When using the {loki-op}, you must now only use the `FORWARD` setting.
 
 [id="network-observability-operator-1.3.0-bug-fixes"]
 === Bug fixes
@@ -193,7 +193,7 @@ The release of Network Observability Operator 1.3 deprecates the `spec.Loki.auth
 === Known issues
 * When `processor.metrics.tls` is set to `PROVIDED` in the `FlowCollector`, the `flowlogs-pipeline` `servicemonitor` is not adapted to the TLS scheme. (link:https://issues.redhat.com/browse/NETOBSERV-1087[*NETOBSERV-1087*])
 
-* Since the 1.2.0 release of the Network Observability Operator, using Loki Operator 5.6, a Loki certificate change periodically affects the `flowlogs-pipeline` pods and results in dropped flows rather than flows written to Loki. The problem self-corrects after some time, but it still causes temporary flow data loss during the Loki certificate change. This issue has only been observed in large-scale environments of 120 nodes or greater.(link:https://issues.redhat.com/browse/NETOBSERV-980[*NETOBSERV-980*])
+* Since the 1.2.0 release of the Network Observability Operator, using {loki-op} 5.6, a Loki certificate change periodically affects the `flowlogs-pipeline` pods and results in dropped flows rather than flows written to Loki. The problem self-corrects after some time, but it still causes temporary flow data loss during the Loki certificate change. This issue has only been observed in large-scale environments of 120 nodes or greater.(link:https://issues.redhat.com/browse/NETOBSERV-980[*NETOBSERV-980*])
 
 [id="network-observability-operator-release-notes-1-2"]
 == Network Observability Operator 1.2.0
@@ -235,7 +235,7 @@ The subscription of an installed Operator specifies an update channel that track
 
 [id="network-observability-operator-1.2.0-known-issues"]
 === Known issue
-* In the 1.2.0 release of the Network Observability Operator, using Loki Operator 5.6, a Loki certificate transition periodically affects the `flowlogs-pipeline` pods and results in dropped flows rather than flows written to Loki. The problem self-corrects after some time, but it still causes temporary flow data loss during the Loki certificate transition. (link:https://issues.redhat.com/browse/NETOBSERV-980[*NETOBSERV-980*])
+* In the 1.2.0 release of the Network Observability Operator, using {loki-op} 5.6, a Loki certificate transition periodically affects the `flowlogs-pipeline` pods and results in dropped flows rather than flows written to Loki. The problem self-corrects after some time, but it still causes temporary flow data loss during the Loki certificate transition. (link:https://issues.redhat.com/browse/NETOBSERV-980[*NETOBSERV-980*])
 
 [id="network-observability-operator-1.2.0-notable-technical-changes"]
 === Notable technical changes
@@ -254,4 +254,4 @@ The Network Observability Operator is now stable and the release channel is upgr
 === Bug fix
 
 * Previously, unless the Loki `authToken` configuration was set to `FORWARD` mode, authentication was no longer enforced, allowing any user who could connect to the {product-title} console in an {product-title} cluster to retrieve flows without authentication.
-Now, regardless of the Loki `authToken` mode, only cluster administrators can retrieve flows. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2169468[*BZ#2169468*])
+Now, regardless of the Loki `authToken` mode, only cluster administrators can retrieve flows. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2169468[*BZ#2169468*])