OLS-1796: OCP docs update, week of 2025/05/26

Author: syedriko

ocp-product-docs-plaintext/4.15/installing/installing_bare_metal_ipi/ipi-install-installation-workflow.txt

@@ -1386,6 +1386,12 @@ The most common use case for this functionality is to specify a static IP addres
 * Configure a PTR DNS record with a valid hostname for each node with a static IP address.
 * Install the NMState CLI (nmstate).
 
+
+[IMPORTANT]
+----
+If you use a provisioning network, configure it by using the dnsmasq tool in Ironic. To do a fully static deployment, you must use virtual media.
+----
+
 1. Optional: Consider testing the NMState syntax with nmstatectl gc before including the syntax in the install-config.yaml file, because the installation program does not check the NMState YAML syntax.
 
 [NOTE]

ocp-product-docs-plaintext/4.15/machine_management/cluster_api_machine_management/cluster-api-troubleshooting.txt

@@ -18,25 +18,16 @@ For clusters that use the Cluster API, OpenShift CLI (`oc`) commands prioritize
 This behavior impacts any oc command that acts upon any object that is represented in both the Cluster API and the Machine API.
 This explanation uses the oc delete machine command, which deletes a machine, as an example.
 
-## Cause
-
-When you run an oc command, oc communicates with the Kube API server to determine which objects to act upon.
+Cause:: When you run an oc command, oc communicates with the Kube API server to determine which objects to act upon.
 The Kube API server uses the first installed custom resource definition (CRD) it encounters alphabetically when an oc command is run.
 
 CRDs for Cluster API objects are in the cluster.x-k8s.io group, while CRDs for Machine API objects are in the machine.openshift.io group.
 Because the letter c precedes the letter m alphabetically, the Kube API server matches on the Cluster API object CRD.
 As a result, the oc command acts upon Cluster API objects.
-
-## Consequences
-
-Due to this behavior, the following unintended outcomes can occur on a cluster that uses the Cluster API:
-
+Consequence:: Due to this behavior, the following unintended outcomes can occur on a cluster that uses the Cluster API:
 * For namespaces that contain both types of objects, commands such as oc get machine return only Cluster API objects.
 * For namespaces that contain only Machine API objects, commands such as oc get machine return no results.
-
-## Workaround
-
-You can ensure that oc commands act on the type of objects you intend by using the corresponding fully qualified name.
+Workaround:: You can ensure that oc commands act on the type of objects you intend by using the corresponding fully qualified name.
 
 * You have access to the cluster using an account with cluster-admin permissions.
 * You have installed the OpenShift CLI (`oc`).

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

@@ -10,7 +10,7 @@ The following example YAML snippets show provider specification and failure doma
 
 ## Sample AWS provider specification
 
-When you create a control plane machine set for an existing cluster, the provider specification must match the providerSpec configuration in the control plane machine custom resource (CR) that is created by the installation program. You can omit any field that is set in the failure domain section of the CR.
+When you create a control plane machine set for an existing cluster, the provider specification must match the providerSpec configuration in the control plane machine custom resource (CR) that the installation program creates. You can omit any field that is set in the failure domain section of the CR.
 
 In the following example, <cluster_id> is the infrastructure ID that is based on the cluster ID that you set when you provisioned the cluster. If you have the OpenShift CLI installed, you can obtain the infrastructure ID by running the following command:
 

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

@@ -10,7 +10,7 @@ The following example YAML snippets show provider specification and failure doma
 
 ## Sample GCP provider specification
 
-When you create a control plane machine set for an existing cluster, the provider specification must match the providerSpec configuration in the control plane machine custom resource (CR) that is created by the installation program. You can omit any field that is set in the failure domain section of the CR.
+When you create a control plane machine set for an existing cluster, the provider specification must match the providerSpec configuration in the control plane machine custom resource (CR) that the installation program creates. You can omit any field that is set in the failure domain section of the CR.
 
 ## Values obtained by using the OpenShift CLI
 

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

@@ -10,7 +10,7 @@ The following example YAML snippet shows a provider specification configuration
 
 ## Sample Nutanix provider specification
 
-When you create a control plane machine set for an existing cluster, the provider specification must match the providerSpec configuration in the control plane machine custom resource (CR) that is created by the installation program.
+When you create a control plane machine set for an existing cluster, the provider specification must match the providerSpec configuration in the control plane machine custom resource (CR) that the installation program creates.
 
 ## Values obtained by using the OpenShift CLI
 

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

@@ -10,7 +10,7 @@ The following example YAML snippets show provider specification and failure doma
 
 ## Sample RHOSP provider specification
 
-When you create a control plane machine set for an existing cluster, the provider specification must match the providerSpec configuration in the control plane machine custom resource (CR) that is created by the installation program.
+When you create a control plane machine set for an existing cluster, the provider specification must match the providerSpec configuration in the control plane machine custom resource (CR) that the installation program creates.
 
 
 ```yaml

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

@@ -10,7 +10,7 @@ The following example YAML snippets show provider specification and failure doma
 
 ## Sample VMware vSphere provider specification
 
-When you create a control plane machine set for an existing cluster, the provider specification must match the providerSpec configuration in the control plane machine custom resource (CR) that is created by the installation program.
+When you create a control plane machine set for an existing cluster, the provider specification must match the providerSpec configuration in the control plane machine custom resource (CR) that the installation program creates.
 
 
 ```yaml

ocp-product-docs-plaintext/4.15/machine_management/creating-infrastructure-machinesets.txt

@@ -1021,7 +1021,7 @@ This sample YAML defines a compute machine set that runs on VMware vSphere and c
 node-role.kubernetes.io/infra: "".
 
 In this sample, <infrastructure_id> is the infrastructure ID label that is based on the cluster ID that you set when you provisioned the cluster, and
-<infra>
+infra
 is the node label to add.
 
 
@@ -1038,24 +1038,21 @@ spec:
   replicas: 1
   selector:
     matchLabels:
-      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
-      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra 2
+      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
+      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra
   template:
     metadata:
       creationTimestamp: null
       labels:
-        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
-        machine.openshift.io/cluster-api-machine-role: <infra> 3
-        machine.openshift.io/cluster-api-machine-type: <infra> 3
-        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra 2
+        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
+        machine.openshift.io/cluster-api-machine-role: infra 3
+        machine.openshift.io/cluster-api-machine-type: infra
+        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra
     spec:
       metadata:
         creationTimestamp: null
         labels:
-          node-role.kubernetes.io/infra: "" 3
-      taints: 4
-      - key: node-role.kubernetes.io/infra
-        effect: NoSchedule
+          node-role.kubernetes.io/infra: ""
       providerSpec:
         value:
           apiVersion: vsphereprovider.openshift.io/v1beta1
@@ -1068,19 +1065,22 @@ spec:
             creationTimestamp: null
           network:
             devices:
-            - networkName: "<vm_network_name>" 5
+            - networkName: "<vm_network_name>" 4
           numCPUs: 4
           numCoresPerSocket: 1
           snapshot: ""
-          template: <vm_template_name> 6
+          template: <vm_template_name> 5
           userDataSecret:
             name: worker-user-data
           workspace:
-            datacenter: <vcenter_datacenter_name> 7
-            datastore: <vcenter_datastore_name> 8
-            folder: <vcenter_vm_folder_path> 9
-            resourcepool: <vsphere_resource_pool> 10
-            server: <vcenter_server_ip> 11
+            datacenter: <vcenter_datacenter_name> 6
+            datastore: <vcenter_datastore_name> 7
+            folder: <vcenter_vm_folder_path> 8
+            resourcepool: <vsphere_resource_pool> 9
+            server: <vcenter_server_ip> 10
+      taints: 11
+      - key: node-role.kubernetes.io/infra
+        effect: NoSchedule
 ```
 
 
@@ -1090,21 +1090,21 @@ Specify the infrastructure ID that is based on the cluster ID that you set when
 $ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
 ```
 
-Specify the infrastructure ID and <infra> node label.
-Specify the <infra> node label.
-Specify a taint to prevent user workloads from being scheduled on infra nodes.
-
-[NOTE]
-----
-After adding the NoSchedule taint on the infrastructure node, existing DNS pods running on that node are marked as misscheduled. You must either delete or add toleration on misscheduled DNS pods.
-----
+Specify the infrastructure ID and infra node label.
+Specify the infra node label.
 Specify the vSphere VM network to deploy the compute machine set to. This VM network must be where other compute machines reside in the cluster.
 Specify the vSphere VM template to use, such as user-5ddjd-rhcos.
 Specify the vCenter Datacenter to deploy the compute machine set on.
 Specify the vCenter Datastore to deploy the compute machine set on.
 Specify the path to the vSphere VM folder in vCenter, such as /dc1/vm/user-inst-5ddjd.
 Specify the vSphere resource pool for your VMs.
 Specify the vCenter server IP or fully qualified domain name.
+Specify a taint to prevent user workloads from being scheduled on infra nodes.
+
+[NOTE]
+----
+After adding the NoSchedule taint on the infrastructure node, existing DNS pods running on that node are marked as misscheduled. You must either delete or add toleration on misscheduled DNS pods.
+----
 
 ## Creating a compute machine set
 

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

@@ -38,21 +38,21 @@ spec:
   replicas: 1
   selector:
     matchLabels:
-      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
-      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> 2
+      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
+      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
   template:
     metadata:
       creationTimestamp: null
       labels:
-        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
+        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
         machine.openshift.io/cluster-api-machine-role: <role> 3
-        machine.openshift.io/cluster-api-machine-type: <role> 3
-        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> 2
+        machine.openshift.io/cluster-api-machine-type: <role>
+        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
     spec:
       metadata:
         creationTimestamp: null
         labels:
-          node-role.kubernetes.io/<role>: "" 3
+          node-role.kubernetes.io/<role>: ""
       providerSpec:
         value:
           apiVersion: vsphereprovider.openshift.io/v1beta1

ocp-product-docs-plaintext/4.15/networking/ovn_kubernetes_network_provider/migrate-from-openshift-sdn.txt

@@ -551,19 +551,13 @@ Metrics are available to monitor the progress of the limited live migration. Met
 1. Enter the following command to generate a token for the prometheus-k8s service account in the openshift-monitoring namespace:
 
 ```terminal
-$ oc create token prometheus-k8s -n openshift-monitoring
-```
-
-Example output
-
-```terminal
-eyJhbGciOiJSUzI1NiIsImtpZCI6IlZiSUtwclcwbEJ2VW9We...
+$ token=`oc create token prometheus-k8s -n openshift-monitoring`
 ```
 
 2. Enter the following command to request information about the openshift_network_operator_live_migration_condition metric:
 
 ```terminal
-$ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -k -H "Authorization: <eyJhbGciOiJSUzI1NiIsImtpZCI6IlZiSUtwclcwbEJ2VW9We...>" "https://<openshift_API_endpoint>" --data-urlencode "query=openshift_network_operator_live_migration_condition" | jq
+$ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -k -H "Authorization: Bearer $token" 'https://thanos-querier.openshift-monitoring.svc:9091/api/v1/query?' --data-urlencode 'query=openshift_network_operator_live_migration_condition' | jq
 ```
 
 Example output