OSDOCS-16572: third batch of rec visibility changes

modules/images-create-guide-openshift.adoc

@@ -72,7 +72,10 @@ For images that are intended to run application code provided by a third party,
 
 Users of your image are able to configure it without having to create a downstream image based on your image. This means that the runtime configuration is handled using environment variables. For a simple configuration, the running process can consume the environment variables directly. For a more complicated configuration or for runtimes which do not support this, configure the runtime by defining a template configuration file that is processed during startup. During this processing, values supplied using environment variables can be substituted into the configuration file or used to make decisions about what options to set in the configuration file.
 
+[NOTE]
+====
 It is also possible and recommended to pass secrets such as certificates and keys into the container using environment variables. This ensures that the secret values do not end up committed in an image and leaked into a container image registry.
+====
 
 Providing environment variables allows consumers of your image to customize behavior, such as database settings, passwords, and performance tuning, without having to introduce a new layer on top of your image. Instead, they can simply define environment variable values when defining a pod and change those settings without rebuilding the image.
 

modules/monitoring-configuring-persistent-storage.adoc

@@ -11,13 +11,16 @@ Run cluster monitoring with persistent storage to gain the following benefits:
 * Protect your metrics and alerting data from data loss by storing them in a persistent volume (PV). As a result, they can survive pods being restarted or recreated.
 * Avoid getting duplicate notifications and losing silences for alerts when the Alertmanager pods are restarted.
 
-For production environments, it is highly recommended to configure persistent storage. 
-
 [IMPORTANT]
 ====
 In multi-node clusters, you must configure persistent storage for Prometheus, Alertmanager, and Thanos Ruler to ensure high availability.
 ====
 
+[NOTE]
+====
+For production environments, it is highly recommended to configure persistent storage.
+====
+
 [id="persistent-storage-prerequisites_{context}"]
 == Persistent storage prerequisites
 

modules/network-observability-dependency-network-observability-operator.adoc

@@ -10,4 +10,9 @@ You can optionally integrate the Network Observability Operator with other compo
 
 {loki-op}:: You can use Loki as the backend to store all collected flows with a maximal level of details. It is recommended to use the Red Hat supported {loki-op} to install Loki. You can also choose to use network observability without Loki, but you need to consider some factors. For more information, see "Network observability without Loki".
 
-AMQ Streams Operator:: Kafka provides scalability, resiliency and high availability in the {product-title} cluster for large scale deployments. If you choose to use Kafka, it is recommended to use Red Hat supported AMQ Streams Operator.
+AMQ Streams Operator:: Kafka provides scalability, resiliency and high availability in the {product-title} cluster for large scale deployments.
++
+[NOTE]
+====
+If you choose to use Kafka, it is recommended to use Red Hat supported AMQ Streams Operator.
+====

modules/nodes-cluster-overcommit-node-resources.adoc

@@ -11,7 +11,11 @@
 To provide more reliable scheduling and minimize node resource overcommitment,
 each node can reserve a portion of its resources for use by system daemons
 that are required to run on your node for your cluster to function.
-In particular, it is recommended that you reserve resources for incompressible resources such as memory.
+
+[NOTE]
+====
+It is recommended that you reserve resources for incompressible resources such as memory.
+====
 
 .Procedure
 

modules/nodes-nodes-resources-configuring-about.adoc

@@ -55,7 +55,11 @@ The node enforces resource constraints by using a new cgroup hierarchy that enfo
 
 Administrators should treat system daemons similar to pods that have a guaranteed quality of service. System daemons can burst within their bounding control groups and this behavior must be managed as part of cluster deployments. Reserve CPU and memory resources for system daemons by specifying the amount of CPU and memory resources in `system-reserved`.
 
-Enforcing `system-reserved` limits can prevent critical system services from receiving CPU and memory resources. As a result, a critical system service can be ended by the out-of-memory killer. The recommendation is to enforce `system-reserved` only if you have profiled the nodes exhaustively to determine precise estimates and you are confident that critical system services can recover if any process in that group is ended by the out-of-memory killer.
+[NOTE]
+====
+Enforcing `system-reserved` limits can prevent critical system services from receiving CPU and memory resources. As a result, a critical system service can be ended by the out-of-memory killer.
+The recommendation is to enforce `system-reserved` only if you have profiled the nodes exhaustively to determine precise estimates and you are confident that critical system services can recover if any process in that group is ended by the out-of-memory killer.
+====
 
 [id="allocate-eviction-thresholds_{context}"]
 == Understanding Eviction Thresholds