OCP docs update, week of 2025/06/02

Author: syedriko

ocp-product-docs-plaintext/4.15/architecture/nvidia-gpu-architecture-overview.txt

@@ -105,7 +105,7 @@ You can deploy Red Hat OpenShift Container Platform to one of the major cloud se
 
 Two modes of operation are available: a fully managed deployment and a self-managed deployment.
 
-* In a fully managed deployment, everything is automated by Red Hat in collaboration with CSP. You can request an OpenShift instance through the CSP web console, and the cluster is automatically created and fully managed by Red Hat. You do not have to worry about node failures or errors in the environment. Red Hat is fully responsible for maintaining the uptime of the cluster. The fully managed services are available on AWS and Azure. For AWS, the OpenShift service is called ROSA (Red Hat OpenShift Service on AWS). For Azure, the service is called Azure Red Hat OpenShift.
+* In a fully managed deployment, everything is automated by Red Hat in collaboration with CSP. You can request an OpenShift instance through the CSP web console, and the cluster is automatically created and fully managed by Red Hat. You do not have to worry about node failures or errors in the environment. Red Hat is fully responsible for maintaining the uptime of the cluster. The fully managed services are available on AWS, Azure, and GCP. For AWS, the OpenShift service is called ROSA (Red Hat OpenShift Service on AWS). For Azure, the service is called Azure Red Hat OpenShift. For GCP, the service is called OpenShift Dedicated on GCP.
 * In a self-managed deployment, you are responsible for instantiating and maintaining the OpenShift cluster. Red Hat provides the OpenShift-install utility to support the deployment of the OpenShift cluster in this case. The self-managed services are available globally to all CSPs.
 
 It is important that this compute instance is a GPU-accelerated compute instance and that the GPU type matches the list of supported GPUs from NVIDIA AI Enterprise. For example, T4, V100, and A100 are part of this list.

ocp-product-docs-plaintext/4.15/installing/install_config/configuring-firewall.txt

@@ -1,8 +1,7 @@
 # Configuring your firewall
 
 
-If you use a firewall, you must configure it so that Red Hat OpenShift Container Platform can access the sites that it requires to function. You must always grant access to some sites, and you grant access to more if you use
-Red Hat Insights, the Telemetry service, a cloud to host your cluster, and certain build strategies.
+If you use a firewall, you must configure it so that Red Hat OpenShift Container Platform can access the sites that it requires to function. You must always grant access to some sites, and you grant access to more if you use Red Hat Insights, the Telemetry service, a cloud to host your cluster, and certain build strategies.
 
 # Configuring your firewall for Red Hat OpenShift Container Platform
 

ocp-product-docs-plaintext/4.15/installing/installing_aws/installing-aws-outposts.txt

@@ -154,12 +154,12 @@ To extend your VPC cluster into an Outpost, you must complete the following netw
 
 ## Changing the cluster network MTU to support AWS Outposts
 
-During installation, the maximum transmission unit (MTU) for the cluster network is detected automatically based on the MTU of the primary network interface of nodes in the cluster.
-You might need to decrease the MTU value for the cluster network to support an AWS Outposts subnet.
+During installation, the maximum transmission unit (MTU) for the cluster network is detected automatically based on the MTU of the primary network interface of nodes in the cluster. You might need to decrease the MTU value for the cluster network to support an AWS Outposts subnet.
 
 
 [IMPORTANT]
 ----
+You cannot roll back an MTU value for nodes during the MTU migration process, but you can roll back the value after the MTU migration process completes.
 The migration is disruptive and nodes in your cluster might be temporarily unavailable as the MTU update takes effect.
 ----
 
@@ -170,6 +170,8 @@ For more details about the migration process, including important service interr
 * You have identified the target MTU for your cluster.
 * The MTU for the OVN-Kubernetes network plugin must be set to 100 less than the lowest hardware MTU value in your cluster.
 * The MTU for the OpenShift SDN network plugin must be set to 50 less than the lowest hardware MTU value in your cluster.
+* If your nodes are physical machines, ensure that the cluster network and the connected network switches support jumbo frames.
+* If your nodes are virtual machines (VMs), ensure that the hypervisor and the connected network switches support jumbo frames.
 
 1. To obtain the current MTU for the cluster network, enter the following command:
 

ocp-product-docs-plaintext/4.15/installing/installing_sno/install-sno-installing-sno.txt

@@ -214,6 +214,11 @@ $ coreos-installer iso ignition embed -fi ocp/bootstrap-in-place-for-live-iso.ig
 ```
 
 
+[IMPORTANT]
+----
+The SSL certificates for the RHCOS ISO installation image are only valid for 24 hours. If you use the ISO image to install a node more than 24 hours after creating the image, the installation can fail. To re-create the image after 24 hours, delete the ocp directory and re-create the Red Hat OpenShift Container Platform assets.
+----
+
 * See Requirements for installing OpenShift on a single node for more information about installing Red Hat OpenShift Container Platform on a single node.
 * See Cluster capabilities for more information about enabling cluster capabilities that were disabled before installation.
 * See Optional cluster capabilities in Red Hat OpenShift Container Platform 4.15 for more information about the features provided by each capability.

ocp-product-docs-plaintext/4.15/installing/overview/cluster-capabilities.txt

@@ -204,7 +204,7 @@ Disable the DeploymentConfig capability only if you do not require DeploymentCon
 
 The Insights Operator provides the features for the Insights capability.
 
-The Insights Operator gathers Red Hat OpenShift Container Platform configuration data and sends it to Red Hat. The data is used to produce proactive insights recommendations about potential issues that a cluster might be exposed to. These insights are communicated to cluster administrators through Insights Advisor on console.redhat.com.
+The Insights Operator gathers Red Hat OpenShift Container Platform configuration data and sends it to Red Hat. The data is used to produce proactive insights recommendations about potential issues that a cluster might be exposed to. These insights are communicated to cluster administrators through the Insights advisor service on console.redhat.com.
 
 ## Notes
 

ocp-product-docs-plaintext/4.15/machine_management/control_plane_machine_management/cpmso_provider_configurations/cpmso-config-options-azure.txt

@@ -438,11 +438,11 @@ The machines should be in the Running state.
 2. For a machine that is running and has a node attached, validate the partition by running the following command:
 
 ```terminal
-$ oc debug node/<node-name> -- chroot /host lsblk
+$ oc debug node/<node_name> -- chroot /host lsblk
 ```
 
 
-In this command, oc debug node/<node-name> starts a debugging shell on the node <node-name> and passes a command with --. The passed command chroot /host provides access to the underlying host OS binaries, and lsblk shows the block devices that are attached to the host OS machine.
+In this command, oc debug node/<node_name> starts a debugging shell on the node <node_name> and passes a command with --. The passed command chroot /host provides access to the underlying host OS binaries, and lsblk shows the block devices that are attached to the host OS machine.
 
 * To use an ultra disk on the control plane, reconfigure your workload to use the control plane's ultra disk mount point.
 

ocp-product-docs-plaintext/4.15/machine_management/creating_machinesets/creating-machineset-azure.txt

@@ -603,11 +603,11 @@ For <role>-user-data-x5, specify the name of the secret. Replace <role> with {ma
 5. Copy an existing Azure MachineSet custom resource (CR) and edit it by running the following command:
 
 ```terminal
-$ oc edit machineset <machine-set-name>
+$ oc edit machineset <machine_set_name>
 ```
 
 
-where <machine-set-name> is the machine set that you want to provision machines with ultra disks.
+where <machine_set_name> is the machine set that you want to provision machines with ultra disks.
 6. Add the following lines in the positions indicated:
 
 ```yaml
@@ -641,7 +641,7 @@ Specify the user data secret created earlier. Replace <role> with {machine-role}
 7. Create a machine set using the updated configuration by running the following command:
 
 ```terminal
-$ oc create -f <machine-set-name>.yaml
+$ oc create -f <machine_set_name>.yaml
 ```
 
 
@@ -656,11 +656,11 @@ The machines should be in the Running state.
 2. For a machine that is running and has a node attached, validate the partition by running the following command:
 
 ```terminal
-$ oc debug node/<node-name> -- chroot /host lsblk
+$ oc debug node/<node_name> -- chroot /host lsblk
 ```
 
 
-In this command, oc debug node/<node-name> starts a debugging shell on the node <node-name> and passes a command with --. The passed command chroot /host provides access to the underlying host OS binaries, and lsblk shows the block devices that are attached to the host OS machine.
+In this command, oc debug node/<node_name> starts a debugging shell on the node <node_name> and passes a command with --. The passed command chroot /host provides access to the underlying host OS binaries, and lsblk shows the block devices that are attached to the host OS machine.
 
 * To use an ultra disk from within a pod, create a workload that uses the mount point. Create a YAML file similar to the following example:
 

ocp-product-docs-plaintext/4.15/networking/changing-cluster-network-mtu.txt

@@ -48,6 +48,7 @@ As a cluster administrator, you can increase or decrease the maximum transmissio
 
 [IMPORTANT]
 ----
+You cannot roll back an MTU value for nodes during the MTU migration process, but you can roll back the value after the MTU migration process completes.
 The migration is disruptive and nodes in your cluster might be temporarily unavailable as the MTU update takes effect.
 ----
 
@@ -58,6 +59,8 @@ The following procedure describes how to change the cluster network MTU by using
 * You have identified the target MTU for your cluster.
 * The MTU for the OVN-Kubernetes network plugin must be set to 100 less than the lowest hardware MTU value in your cluster.
 * The MTU for the OpenShift SDN network plugin must be set to 50 less than the lowest hardware MTU value in your cluster.
+* If your nodes are physical machines, ensure that the cluster network and the connected network switches support jumbo frames.
+* If your nodes are virtual machines (VMs), ensure that the hypervisor and the connected network switches support jumbo frames.
 
 1. To obtain the current MTU for the cluster network, enter the following command:
 

ocp-product-docs-plaintext/4.15/networking/dns-operator.txt

@@ -354,6 +354,24 @@ $ oc get configmap/dns-default -n openshift-dns -o yaml
 ```
 
 
+# Viewing the CoreDNS logs
+
+You can view CoreDNS logs by using the oc logs command.
+
+* View the logs of a specific CoreDNS pod by entering the following command:
+
+```terminal
+$ oc -n openshift-dns logs -c dns <core_dns_pod_name>
+```
+
+* Follow the logs of all CoreDNS pods by entering the following command:
+
+```terminal
+$ oc -n openshift-dns logs -c dns -l dns.operator.openshift.io/daemonset-dns=default -f --max-log-requests=<number> 1
+```
+
+Specifies the number of DNS pods to stream logs from. The maximum is 6.
+
 # Setting the CoreDNS Operator log level
 
 Cluster administrators can configure the Operator log level to more quickly track down OpenShift DNS issues. The valid values for operatorLogLevel are Normal, Debug, and Trace. Trace has the most detailed information. The default operatorlogLevel is Normal. There are seven logging levels for issues: Trace, Debug, Info, Warning, Error, Fatal and Panic. After the logging level is set, log entries with that severity or anything above it will be logged.

ocp-product-docs-plaintext/4.15/nodes/pods/nodes-pods-vertical-autoscaler.txt

@@ -616,6 +616,49 @@ spec:
 ```
 
 
+## Custom memory bump-up after OOM event
+
+If your cluster experiences an OOM (out of memory) event, the Vertical Pod Autoscaler Operator (VPA) increases the memory recommendation based on the memory consumption observed during the OOM event and a specified multiplier value in order to prevent future crashes due to insufficient memory.
+
+The recommendation is the higher of two calculations: the memory in use by the pod when the OOM event happened multiplied by a specified number of bytes or a specified percentage. The calculation is represented by the following formula:
+
+
+```text
+recommendation = max(memory-usage-in-oom-event + oom-min-bump-up-bytes, memory-usage-in-oom-event * oom-bump-up-ratio)
+```
+
+
+You can configure the memory increase by specifying the following values in the recommender pod:
+
+* oom-min-bump-up-bytes. This value, in bytes, is a specific increase in memory after an OOM event occurs. The default is 100MiB.
+* oom-bump-up-ratio. This value is a percentage increase in memory when the OOM event occurred. The default value is 1.2.
+
+For example, if the pod memory usage during an OOM event is 100MB, and oom-min-bump-up-bytes is set to 150MB with a oom-min-bump-ratio of 1.2, after an OOM event, the VPA would recommend increasing the memory request for that pod to 150 MB, as it is higher than at 120MB (100MB * 1.2).
+
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: vpa-recommender-default
+  namespace: openshift-vertical-pod-autoscaler
+# ...
+spec:
+# ...
+  template:
+# ...
+    spec
+      containers:
+      - name: recommender
+        args:
+        - --oom-bump-up-ratio=2.0
+        - --oom-min-bump-up-bytes=524288000
+# ...
+```
+
+
+* Understanding OOM kill policy
+
 ## Using an alternative recommender
 
 You can use your own recommender to autoscale based on your own algorithms. If you do not specify an alternative recommender, Red Hat OpenShift Container Platform uses the default recommender, which suggests CPU and memory requests based on historical usage. Because there is no universal recommendation policy that applies to all types of workloads, you might want to create and deploy different recommenders for specific workloads.