Merge pull request #78071 from eromanova97/OBSDOCS-1155

sheriff-rh · web-flow · commit 9a89b95c2ec3 · 2024-07-09T08:32:49.000-04:00
diff --git a/modules/monitoring-adding-a-secret-to-the-alertmanager-configuration.adoc b/modules/monitoring-adding-a-secret-to-the-alertmanager-configuration.adoc
@@ -129,5 +129,5 @@ data:
       - test-api-receiver-token
 ----
 
-. Save the file to apply the changes to the `ConfigMap` object. The new configuration is applied automatically.
+. Save the file to apply the changes. The new configuration is applied automatically.
 
diff --git a/modules/monitoring-assigning-tolerations-to-monitoring-components.adoc b/modules/monitoring-assigning-tolerations-to-monitoring-components.adoc
@@ -125,9 +125,4 @@ data:
         effect: "NoSchedule"
 ----
 
-. Save the file to apply the changes. The new component placement configuration is applied automatically.
-+
-[WARNING]
-====
-When changes are saved to a monitoring config map, the pods and other resources in the related project might be redeployed. The running monitoring processes in that project might also be restarted.
-====
+. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
diff --git a/modules/monitoring-attaching-additional-labels-to-your-time-series-and-alerts.adoc b/modules/monitoring-attaching-additional-labels-to-your-time-series-and-alerts.adoc
@@ -78,6 +78,8 @@ data:
         environment: prod
 ----
 
+.. Save the file to apply the changes. The new configuration is applied automatically.
+
 ** *To attach custom labels to all time series and alerts leaving the Prometheus instance that monitors user-defined projects*:
 endif::openshift-dedicated,openshift-rosa[]
 .. Edit the `user-workload-monitoring-config` `ConfigMap` object in the `openshift-user-workload-monitoring` project:
@@ -134,9 +136,4 @@ data:
         environment: prod
 ----
 
-. Save the file to apply the changes. The new configuration is applied automatically.
-+
-[WARNING]
-====
-When changes are saved to a monitoring config map, the pods and other resources in the related project might be redeployed. The running monitoring processes in that project might also be restarted.
-====
+.. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
diff --git a/modules/monitoring-choosing-a-metrics-collection-profile.adoc b/modules/monitoring-choosing-a-metrics-collection-profile.adoc
@@ -15,12 +15,6 @@ To choose a metrics collection profile for core {product-title} monitoring compo
 * You have created the `cluster-monitoring-config` `ConfigMap` object.
 * You have access to the cluster as a user with the `cluster-admin` cluster role.
 
-[WARNING]
-====
-Saving changes to a monitoring config map might restart monitoring processes and redeploy the pods and other resources in the related project.
-The running monitoring processes in that project might also restart.
-====
-
 .Procedure
 
 . Edit the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` project:
@@ -64,4 +58,4 @@ data:
       collectionProfile: *minimal*
 ----
 
-. Save the file to apply the changes. The pods affected by the new configuration restart automatically.
+. Save the file to apply the changes. The new configuration is applied automatically.
diff --git a/modules/monitoring-configuring-a-persistent-volume-claim.adoc b/modules/monitoring-configuring-a-persistent-volume-claim.adoc
@@ -141,11 +141,9 @@ data:
 Storage requirements for the `thanosRuler` component depend on the number of rules that are evaluated and how many samples each rule generates.
 ====
 
-. Save the file to apply the changes. The pods affected by the new configuration are restarted automatically and the new storage configuration is applied.
-ifdef::openshift-dedicated,openshift-rosa[]
+. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed and the new storage configuration is applied.
 +
 [WARNING]
 ====
-When changes are saved to a monitoring config map, the pods and other resources in the related project might be redeployed. The running monitoring processes in that project might also be restarted.
+When you update the config map with a PVC configuration, the affected `StatefulSet` object is recreated, resulting in a temporary service outage.
 ====
-endif::openshift-dedicated,openshift-rosa[]
diff --git a/modules/monitoring-configuring-external-alertmanagers.adoc b/modules/monitoring-configuring-external-alertmanagers.adoc
@@ -164,6 +164,4 @@ data:
         - external-alertmanager1-remote2.com
 ----
 
-. Save the file to apply the changes to the `ConfigMap` object. The new component placement configuration is applied automatically.
-
-. Save the file to apply the changes to the `ConfigMap` object. The new component placement configuration is applied automatically.
+. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
diff --git a/modules/monitoring-configuring-pod-topology-spread-constraints.adoc b/modules/monitoring-configuring-pod-topology-spread-constraints.adoc
@@ -102,13 +102,7 @@ data:
             app.kubernetes.io/name: prometheus
 ----
 
-. Save the file to apply the changes automatically.
-+
-[WARNING]
-====
-When you save changes to the `cluster-monitoring-config` config map, the pods and other resources in the `openshift-monitoring` project might be redeployed.
-The running monitoring processes in that project might also restart.
-====
+. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
 
 * *To configure pod topology spread constraints for user-defined monitoring:*
 endif::openshift-dedicated,openshift-rosa[]
@@ -171,10 +165,4 @@ data:
             app.kubernetes.io/name: thanos-ruler
 ----
 
-. Save the file to apply the changes automatically.
-+
-[WARNING]
-====
-When you save changes to the `user-workload-monitoring-config` config map, the pods and other resources in the `openshift-user-workload-monitoring` project might be redeployed.
-The running monitoring processes in that project might also restart.
-====
+. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
diff --git a/modules/monitoring-configuring-remote-write-storage.adoc b/modules/monitoring-configuring-remote-write-storage.adoc
@@ -201,9 +201,4 @@ data:
 +
 See the link:https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config[Prometheus relabel_config documentation] for information about write relabel configuration options.
 
-. Save the file to apply the changes. The pods affected by the new configuration restart automatically.
-+
-[WARNING]
-====
-Saving changes to a monitoring `ConfigMap` object might redeploy the pods and other resources in the related project. Saving changes might also restart the running monitoring processes in that project.
-====
+. Save the file to apply the changes. The new configuration is applied automatically.
diff --git a/modules/monitoring-configuring-the-monitoring-stack.adoc b/modules/monitoring-configuring-the-monitoring-stack.adoc
@@ -136,9 +136,21 @@ The Prometheus config map component is called `prometheusK8s` in the `cluster-mo
 ====
 endif::openshift-dedicated,openshift-rosa[]
 
-. Save the file to apply the changes to the `ConfigMap` object. The pods affected by the new configuration are restarted automatically.
+. Save the file to apply the changes to the `ConfigMap` object.
 +
 [WARNING]
 ====
-When changes are saved to a monitoring config map, the pods and other resources in the related project might be redeployed. The running monitoring processes in that project might also be restarted.
+Different configuration changes to the `ConfigMap` object result in different outcomes:
+
+* The pods are not redeployed. Therefore, there is no service outage.
+
+* The affected pods are redeployed:
+
+** For single-node clusters, this results in temporary service outage.
+
+** For multi-node clusters, because of high-availability, the affected pods are gradually rolled out and the monitoring stack remains available.
+
+** Configuring and resizing a persistent volume always results in a service outage, regardless of high availability.
+
+Each procedure that requires a change in the config map includes its expected outcome.
 ====
diff --git a/modules/monitoring-creating-cluster-id-labels-for-metrics.adoc b/modules/monitoring-creating-cluster-id-labels-for-metrics.adoc
@@ -157,10 +157,4 @@ data:
 <2> Specify the name of the cluster ID label for metrics sent to remote write storage. If you use a label name that already exists for a metric, that value is overwritten with the name of this cluster ID label. For the label name, do not use `+++__tmp_openshift_cluster_id__+++`. The final relabeling step removes labels that use this name.
 <3> The `replace` write relabel action replaces the temporary label with the target label for outgoing metrics. This action is the default and is applied if no action is specified.
 
-. Save the file to apply the changes to the `ConfigMap` object.
-The pods affected by the updated configuration automatically restart.
-+
-[WARNING]
-====
-Saving changes to a monitoring `ConfigMap` object might redeploy the pods and other resources in the related project. Saving changes might also restart the running monitoring processes in that project.
-====
+. Save the file to apply the changes. The new configuration is applied automatically.
diff --git a/modules/monitoring-creating-cluster-monitoring-configmap.adoc b/modules/monitoring-creating-cluster-monitoring-configmap.adoc
@@ -8,11 +8,6 @@
 
 You can configure the core {product-title} monitoring components by creating the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` project. The Cluster Monitoring Operator (CMO) then configures the core components of the monitoring stack.
 
-[NOTE]
-====
-When you save your changes to the `cluster-monitoring-config` `ConfigMap` object, some or all of the pods in the `openshift-monitoring` project might be redeployed. It can sometimes take a while for these components to redeploy.
-====
-
 .Prerequisites
 
 * You have access to the cluster as a user with the `cluster-admin` cluster role.
diff --git a/modules/monitoring-enabling-monitoring-for-user-defined-projects.adoc b/modules/monitoring-enabling-monitoring-for-user-defined-projects.adoc
@@ -60,11 +60,6 @@ data:
 ====
 If you enable monitoring for user-defined projects, the `user-workload-monitoring-config` `ConfigMap` object is created by default.
 ====
-+
-[WARNING]
-====
-When changes are saved to the `cluster-monitoring-config` `ConfigMap` object, the pods and other resources in the `openshift-monitoring` project might be redeployed. The running monitoring processes in that project might also be restarted.
-====
 
 . Verify that the `prometheus-operator`, `prometheus-user-workload`, and `thanos-ruler-user-workload` pods are running in the `openshift-user-workload-monitoring` project. It might take a short while for the pods to start:
 +
diff --git a/modules/monitoring-enabling-query-logging-for-thanos-querier.adoc b/modules/monitoring-enabling-query-logging-for-thanos-querier.adoc
@@ -51,12 +51,7 @@ data:
 <1> Set the value to `true` to enable logging and `false` to disable logging. The default value is `false`.
 <2> Set the value to `debug`, `info`, `warn`, or `error`. If no value exists for `logLevel`, the log level defaults to `error`.
 +
-. Save the file to apply the changes.
-+
-[WARNING]
-====
-When you save changes to a monitoring config map, pods and other resources in the related project might be redeployed. The running monitoring processes in that project might also be restarted.
-====
+. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
 
 .Verification
 
diff --git a/modules/monitoring-enabling-the-platform-alertmanager-instance-for-user-defined-alert-routing.adoc b/modules/monitoring-enabling-the-platform-alertmanager-instance-for-user-defined-alert-routing.adoc
@@ -38,4 +38,4 @@ data:
 ----
 <1> Set the `enableUserAlertmanagerConfig` value to `true` to allow users to create user-defined alert routing configurations that use the main platform instance of Alertmanager.
 +
-. Save the file to apply the changes.
+. Save the file to apply the changes. The new configuration is applied automatically.
diff --git a/modules/monitoring-investigating-why-user-defined-metrics-are-unavailable.adoc b/modules/monitoring-investigating-why-user-defined-metrics-are-unavailable.adoc
@@ -132,12 +132,7 @@ data:
 # ...
 ----
 +
-.. Save the file to apply the changes.
-+
-[NOTE]
-====
-The `prometheus-operator` in the `openshift-user-workload-monitoring` project restarts automatically when you apply the log-level change.
-====
+.. Save the file to apply the changes. The affected `prometheus-operator` pod is automatically redeployed.
 +
 .. Confirm that the `debug` log-level has been applied to the `prometheus-operator` deployment in the `openshift-user-workload-monitoring` project:
 +
diff --git a/modules/monitoring-modifying-retention-time-and-size-for-prometheus-metrics-data.adoc b/modules/monitoring-modifying-retention-time-and-size-for-prometheus-metrics-data.adoc
@@ -146,9 +146,4 @@ data:
       retentionSize: 10GB
 ----
 
-. Save the file to apply the changes. The pods affected by the new configuration restart automatically.
-+
-[WARNING]
-====
-When changes are saved to a monitoring config map, the pods and other resources in the related project might be redeployed. The running monitoring processes in that project might also be restarted.
-====
+. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
diff --git a/modules/monitoring-modifying-the-retention-time-for-thanos-ruler-metrics-data.adoc b/modules/monitoring-modifying-the-retention-time-for-thanos-ruler-metrics-data.adoc
@@ -63,10 +63,4 @@ data:
       retention: 10d
 ----
 
-. Save the file to apply the changes. The pods affected by the new configuration automatically restart.
-+
-[WARNING]
-====
-Saving changes to a monitoring config map might restart monitoring processes and redeploy the pods and other resources in the related project.
-The running monitoring processes in that project might also restart.
-====
+. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
diff --git a/modules/monitoring-moving-monitoring-components-to-different-nodes.adoc b/modules/monitoring-moving-monitoring-components-to-different-nodes.adoc
@@ -117,11 +117,4 @@ If you specify additional labels, the pods for the component are only scheduled
 If monitoring components remain in a `Pending` state after configuring the `nodeSelector` constraint, check the pod events for errors relating to taints and tolerations.
 ====
 
-. Save the file to apply the changes.
-The components specified in the new configuration are moved to the new nodes automatically.
-+
-[WARNING]
-====
-When you save changes to a monitoring config map, the pods and other resources in the project might be redeployed.
-The running monitoring processes in that project might also restart.
-====
+. Save the file to apply the changes. The components specified in the new configuration are automatically moved to the new nodes, and the pods affected by the new configuration are redeployed.
diff --git a/modules/monitoring-resizing-a-persistent-volume.adoc b/modules/monitoring-resizing-a-persistent-volume.adoc
@@ -137,9 +137,9 @@ data:
 Storage requirements for the `thanosRuler` component depend on the number of rules that are evaluated and how many samples each rule generates.
 ====
 
-. Save the file to apply the changes.
+. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
 +
 [WARNING]
 ====
-When you save changes to a monitoring config map, the pods and other resources in the related project are redeployed. The monitoring processes running in that project are restarted.
+When you update the config map with a new storage size, the affected `StatefulSet` object is recreated, resulting in a temporary service outage.
 ====
diff --git a/modules/monitoring-setting-audit-log-levels-for-the-prometheus-adapter.adoc b/modules/monitoring-setting-audit-log-levels-for-the-prometheus-adapter.adoc
@@ -50,12 +50,7 @@ data:
 * `Request`: Log only the metadata and the request text but not the response text. This option does not apply for non-resource requests.
 * `RequestResponse`: Log event metadata, request text, and response text. This option does not apply for non-resource requests.
 
-. Save the file to apply the changes. The pods for the Prometheus Adapter restart automatically when you apply the change.
-+
-[WARNING]
-====
-When changes are saved to a monitoring config map, the pods and other resources in the related project might be redeployed. The running monitoring processes in that project might also be restarted.
-====
+. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
 
 .Verification
 
diff --git a/modules/monitoring-setting-log-levels-for-monitoring-components.adoc b/modules/monitoring-setting-log-levels-for-monitoring-components.adoc
@@ -103,12 +103,7 @@ data:
 For user workload monitoring, available component values are `alertmanager`, `prometheus`, `prometheusOperator`, and `thanosRuler`.
 <2> The log level to apply to the component. The available values are `error`, `warn`, `info`, and `debug`. The default value is `info`.
 
-. Save the file to apply the changes. The pods for the component restart automatically when you apply the log-level change.
-+
-[WARNING]
-====
-When changes are saved to a monitoring config map, the pods and other resources in the related project might be redeployed. The running monitoring processes in that project might also be restarted.
-====
+. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
 
 . Confirm that the log-level has been applied by reviewing the deployment or pod configuration in the related project. The following example checks the log level in the `prometheus-operator` deployment in the `openshift-user-workload-monitoring` project:
 +
diff --git a/modules/monitoring-setting-query-log-file-for-prometheus.adoc b/modules/monitoring-setting-query-log-file-for-prometheus.adoc
@@ -60,12 +60,7 @@ data:
 ----
 <1> The full path to the file in which queries will be logged.
 +
-. Save the file to apply the changes.
-+
-[WARNING]
-====
-When you save changes to a monitoring config map, pods and other resources in the related project might be redeployed. The running monitoring processes in that project might also be restarted.
-====
+. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
 +
 . Verify that the pods for the component are running. The following sample command lists the status of pods in the `openshift-monitoring` project:
 +
@@ -111,12 +106,7 @@ data:
 ----
 <1> The full path to the file in which queries will be logged.
 +
-. Save the file to apply the changes.
-+
-[WARNING]
-====
-When you save changes to a monitoring config map, pods and other resources in the related project might be redeployed. The running monitoring processes in that project might also be restarted.
-====
+. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
 +
 . Verify that the pods for the component are running. The following example command lists the status of pods in the `openshift-user-workload-monitoring` project:
 +
diff --git a/modules/monitoring-setting-scrape-sample-and-label-limits-for-user-defined-projects.adoc b/modules/monitoring-setting-scrape-sample-and-label-limits-for-user-defined-projects.adoc
@@ -74,8 +74,3 @@ The default value is `0`, which specifies no limit.
 The default value is `0`, which specifies no limit.
 
 . Save the file to apply the changes. The limits are applied automatically.
-+
-[WARNING]
-====
-When changes are saved to the `user-workload-monitoring-config` `ConfigMap` object, the pods and other resources in the `openshift-user-workload-monitoring` project might be redeployed. The running monitoring processes in that project might also be restarted.
-====
diff --git a/modules/monitoring-setting-the-body-size-limit-for-metrics-scraping.adoc b/modules/monitoring-setting-the-body-size-limit-for-metrics-scraping.adoc
@@ -52,10 +52,4 @@ Valid numeric values use the Prometheus data size format: B (bytes), KB (kilobyt
 The default value is `0`, which specifies no limit.
 You can also set the value to `automatic` to calculate the limit automatically based on cluster capacity.
 
-. Save the file to apply the changes automatically.
-+
-[WARNING]
-====
-When you save changes to a `cluster-monitoring-config` config map, the pods and other resources in the `openshift-monitoring` project might be redeployed.
-The running monitoring processes in that project might also restart.
-====
+. Save the file to apply the changes. The new configuration is applied automatically.
diff --git a/modules/monitoring-specifying-limits-and-requests-for-monitoring-components.adoc b/modules/monitoring-specifying-limits-and-requests-for-monitoring-components.adoc
@@ -138,13 +138,7 @@ data:
           memory: 50Mi
 ----
 
-. Save the file to apply the changes automatically.
-+
-[IMPORTANT]
-====
-When you save changes to the `cluster-monitoring-config` config map, the pods and other resources in the `openshift-monitoring` project might be redeployed.
-The running monitoring processes in that project might also restart.
-====
+. Save the file to apply the changes. The pods affected by the new configuration are automatically redeployed.
 
 [role="_additional-resources"]
 .Additional resources
