gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: This documentation details the Red Hat responsibilities for the {product-title} managed service.
A Red Hat Site Reliability Engineer (SRE) maintains a centralized monitoring and alerting system for all {product-title} cluster components, SRE services, and underlying cloud provider accounts. Platform audit logs are securely forwarded to a centralized SIEM (Security Information and Event Monitoring) system, where they might trigger configured alerts to the SRE team and are also subject to manual review. Audit logs are retained in the SIEM for one year. Audit logs for a given cluster are not deleted at the time the cluster is deleted.
An incident is an event that results in a degradation or outage of one or more Red Hat services. An incident can be raised by a customer or Customer Experience and Engagement (CEE) member through a support case, directly by the centralized monitoring and alerting system, or directly by a member of the SRE team.
The general workflow of how a new incident is managed by Red Hat:
. The incident is recovered.
. The incident is documented and a root cause analysis is performed within 5 business days of the incident.
. A root cause analysis (RCA) draft document is shared with the customer within 7 business days of the incident.
Revised: . The customer must make a request for the additional information within 5 business days of the incident resolution.
Original: * If your nodes are physical machines, ensure that the cluster network, which includes network switches, supports jumbo frames. 
* If your nodes are virtual machines (VMs), ensure that the hypervisor and the connected network switches support jumbo frames.
Revised: * 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.
Original: * Previously, the *Observe* section on the web console did not show items contributed from plugins unless certain flags related to the monitoring were set. These flags prevented other plugins, such as logging, distributed tracing, network observability, and others from adding items to the *Observe* section. With this release, the monitoring flags are removed so that other plugins can add items to the *Observe* section. (link:https://issues.redhat.com/browse/OCPBUGS-53437[OCPBUGS-53437])
Revised: * Previously, the *Observe* section on the web console did not show items contributed from plugins unless certain flags related to the monitoring were set. These flags prevented other plugins, such as logging, {DTShortName}, network observability, and others from adding items to the *Observe* section. With this release, the monitoring flags are removed so that other plugins can add items to the *Observe* section. (link:https://issues.redhat.com/browse/OCPBUGS-53437[OCPBUGS-53437])
Original: * In some cases, {microshift-short} did not start when using the default configuration file shipped in the {microshift-short} RPM. Certain required values were missing from the configuration file. These values are now added to the default `config.yaml` to avoid this problem and {microshift-short} starts as expected. (link:https://issues.redhat.com/browse/OCPBUGS-53026[*OCPBUGS-53026*])
Revised: * In some cases, {microshift-short} did not start when using the default configuration file shipped in the {microshift-short} RPM due to certain required values that were missing. These values are now added to the default `config.yaml` file to avoid this problem and {microshift-short} starts as expected. (link:https://issues.redhat.com/browse/OCPBUGS-53026[*OCPBUGS-53026*])
Original: * Previously, a failed greenboot health check flag did not clear when an RPM-install-based {microshift-short} service was updated without rebooting the system. As a consequence, greenboot health checks for optional components continue to fail because the `systemctl restart greenboot-healthcheck.service` command fails while the flag is present. With this release, the primary {microshift-short} greenboot health check clears the condition that causes optional component health checks to continue to fail. (link:https://issues.redhat.com/browse/OCPBUGS-51198[*OCPBUGS-51198*])
Revised: * Previously, {microshift-short} could fail to start on a host without the hostname RPM package installed. With this release, the hostname RPM package is pulled as a dependency during installation. This change means that the hostname RPM package is now required when building the {microshift-short} system, preventing this type of startup failure. (link:https://issues.redhat.com/browse/OCPBUGS-54448[OCPBUGS-54448])
Original: [NOTE]
====
If additional LUNs are configured with NPIV, FCP requires `zfcp.allow_lun_scan=0`. If you must enable `zfcp.allow_lun_scan=1` because you use a CSI driver, for example, you must configure your NPIV so that each node cannot access the boot partition of another node.
====
... Leave all other parameters unchanged.
Revised: .Example `generic.ins` file
Original: [NOTE]
====
If additional LUNs are configured with NPIV, FCP requires `zfcp.allow_lun_scan=0`. If you must enable `zfcp.allow_lun_scan=1` because you use a CSI driver, for example, you must configure your NPIV so that each node cannot access the boot partition of another node.
====
... Leave all other parameters unchanged.
Revised: Some installation methods also require a `generic.ins` file with a mapping of the location of the installation data in the file system of the Hardware Management Console (HMC), the DVD, or the FTP server and the memory locations where the data is to be copied. A `sample generic.ins` file is provided with the {op-system-base} installation media. The file contains file names for the initial RAM disk (`initrd.img`), the kernel image (`kernel.img`), and the parameter , (`generic.prm`) files and a memory location for each file.
Original: coreos.inst.install_dev=/dev/<block_device> \// <1>
rd.dasd=0.0.3490 \
zfcp.allow_lun_scan=0
<1> Specify the block device type. For installations on DASD-type disks, specify `/dev/dasda`. For installations on FCP-type disks, specify `/dev/sda`.
Revised: <1> Specify a unique fully qualified path depending on disk type. This can be either DASD-type or FCP-type disks.
Original: coreos.inst.install_dev=/dev/<block_device> \// <1>
rd.dasd=0.0.3490 \
zfcp.allow_lun_scan=0
<1> Specify the block device type. For installations on DASD-type disks, specify `/dev/dasda`. For installations on FCP-type disks, specify `/dev/sda`.
<1> Specify the block device type. For installations on DASD-type disks, specify `/dev/dasda`. For installations on FCP-type disks, specify `/dev/sda`. For installations on NVMe-type disks, specify `/dev/nvme0n1`.
Revised: <1> Specify a unique fully qualified path depending on disk type. This can be either DASD-type, FCP-type, or NVMe-type disks.
Original: See the latest images included with {microshift-short} by xref:../microshift_updating/microshift-list-update-contents.adoc#microshift-get-rpm-release-info_microshift-list-update-contents[listing the contents of the {microshift-short} RPM release package].
Revised: * Previously, an IPv6 configuration for {microshift-short} was created in the system at first start when an IP address was not configured. This was caused by an erroneous retrieval of the default node IP address because of the order in which the interfaces were listed. Consequentially, the misconfiguration resulted in services being unreachable. With this release, the correct node IP address is retrieved first. (link:https://issues.redhat.com/browse/OCPBUGS-52861[OCPBUGS-52861])
Original: * Previously, when you selected the load balancer, the installer picked a fixed internet protocol (IP) (`10.0.0.100`) and set it to the load balancer even if the IP was outside of the range of the machine network or virtual network. A new variable IP check now verifies whether an available IP can be used by the load balancer in the machine network or virtual network. With this release, the installer checks for an available IP in the provided control plane subnet or machine network and elects an IP that is not reserved if the default IP is not within the range. (link:https://issues.redhat.com/browse/OCPBUGS-55224[*OCPBUGS-55224*])
Revised: * Previously, when you selected the load balancer, the installation program picked a fixed internet protocol (IP) address, (`10.0.0.100`), and attached the address to the load balancer even if the IP was outside of the range of the machine network or virtual network. With this release, the installation program checks for an available IP in the provided control plane subnet or machine network and elects an IP that is not reserved if the default IP is not within the range. (link:https://issues.redhat.com/browse/OCPBUGS-55224[*OCPBUGS-55224*])
Original: * Previously, if a scrape failed, Prometheus erroneously considered the samples from the very next scrape as duplicates and dropped them. This issue affected only the scrape immediately following a failure, while subsequent scrapes were processed correctly. With this release, the scrape following a failure is now correctly handled, ensuring that no valid samples are mistakenly dropped. (link:https://issues.redhat.com/browse/OCPBUGS-54941[*OCPBUGS-54941*])
Revised: * Previously, if a scrape failed, Prometheus erroneously considered the samples from the very next scrape as duplicates and dropped them. This issue impacted only the scrape immediately following a failure, while subsequent scrapes were processed correctly. With this release, the scrape following a failure is now correctly handled, ensuring that no valid samples are mistakenly dropped. (link:https://issues.redhat.com/browse/OCPBUGS-54941[*OCPBUGS-54941*])
Original: * Previously, for an Ingress resource with an `IngressWithoutClassName` alert, the Ingress Controller did not delete the alert along with deletion of the resource. The alert continued to show on the {product-title} web console. With this release, the Ingress Controller resets the `openshift_ingress_to_route_controller_ingress_without_class_name` metric to `0` before the controller deletes the Ingress resource, so that the alert is deleted and no longer shows on the web console.  (link:https://issues.redhat.com/browse/OCPBUGS-53077[*OCPBUGS-53077*])
Revised: * Previously, for an Ingress resource with an `IngressWithoutClassName` alert, the Ingress Controller did not delete the alert along with deletion of the resource. The alert continued to show on the {product-title} web console. With this release, the Ingress Controller resets the `openshift_ingress_to_route_controller_ingress_without_class_name` metric to `0` before the controller deletes the Ingress resource, so that the alert is deleted and no longer shows on the web console. (link:https://issues.redhat.com/browse/OCPBUGS-53077[*OCPBUGS-53077*])
Original: * There is a known issue when the grandmaster clock (T-GM) transitions to the Locked state too soon. This happens before the Digital Phase-Locked Loop (DPLL) completes its transition to the `Locked-HO-Acquired` state, and after the Global Navigation Satellite Systems (GNSS) time source is restored.
Revised: [id="ocp-4-17-27-bug-fixes_{context}"]
==== Bug fixes
Original: * There is a known issue when the grandmaster clock (T-GM) transitions to the Locked state too soon. This happens before the Digital Phase-Locked Loop (DPLL) completes its transition to the `Locked-HO-Acquired` state, and after the Global Navigation Satellite Systems (GNSS) time source is restored.
Revised: * There is a known issue when the grandmaster clock (T-GM) transitions to the Locked state too soon. This happens before the Digital Phase-Locked Loop (DPLL) completes its transition to the `Locked-HO-Acquired` state, and after the Global Navigation Satellite Systems (GNSS) time source is restored. (link:https://issues.redhat.com/browse/OCPBUGS-54534[*OCPBUGS-54534*])
Original: * Previously, the Single Root I/O Virtualization (SR-IOV) virtual function (VF) did not revert any unexpected value changes to the maximum transmission unit (MTU) value when a pod was deleted. This issue occurred if the is the application inside the pod had its MTU value changed; in turn, the pod would also have its MTU value changed. With this release, the SR-IOV Container Network Interface (CNI) now reverts any unexpected MTU value changes to the original value so that this issue no longer exists. (link:https://issues.redhat.com/browse/OCPBUGS-54392[*OCPBUGS-54392*]) 
Revised: * Previously, the Single Root I/O Virtualization (SR-IOV) virtual function (VF) did not revert any unexpected value changes to the maximum transmission unit (MTU) value when a pod was deleted. This issue occurred if the application inside the pod had its MTU value changed; in turn, the pod would also have its MTU value changed. With this release, the SR-IOV Container Network Interface (CNI) now reverts any unexpected MTU value changes to the original value so that this issue no longer exists. (link:https://issues.redhat.com/browse/OCPBUGS-54392[*OCPBUGS-54392*])
Original: With {oadp-short} 1.5.0, the `configuration.restic.podConfig.resourceAllocations` specification field is removed from Data Protection Application (DPA). Use a `nodeAgent` pod instead of the `Restic` pod.
Revised: With {oadp-short} 1.5.0, the `configuration.restic.podConfig.resourceAllocations` specification field is removed from the `DataProtectionApplication` (DPA) custom resource. Use the `nodeAgent` section with the `uploaderType` field set to `Kopia` instead of  `Restic` .
Original: {op-system} is supported only as a component of {product-title} {product-version} for all {product-title} machines. {op-system} is the only supported operating system for {product-title} control plane, or master, machines. While {op-system} is the default operating system for all cluster machines, you can create compute machines, which are also known as worker machines, that use {op-system-base} as their operating system. There are two general ways {op-system} is deployed in {product-title} {product-version}:
Revised: {op-system} is supported only as a component of {product-title} {product-version} for all {product-title} machines. {op-system} is the only supported operating system for all node types in {product-title}. {op-system} is deployed in {product-title} {product-version} in two general ways:
Original: Also, because Windows nodes configured by the WMCO rely on containerd container runtime, the WMCO ensures that the containerd config files are up-to-date with the registry settings. For new nodes, these files are copied to the instances upon creation. For existing nodes, after activating the mirror registry, the registry controller uses SSH to access each node and copy the generated config files, replacing any existing files.
Revised: * Mirroring on Windows nodes works on the registry level, rather than on the image level used by Linux nodes. As such, Windows images mirrored through IDMS and ITMS objects have specific naming requirements.
Original: Also, because Windows nodes configured by the WMCO rely on containerd container runtime, the WMCO ensures that the containerd config files are up-to-date with the registry settings. For new nodes, these files are copied to the instances upon creation. For existing nodes, after activating the mirror registry, the registry controller uses SSH to access each node and copy the generated config files, replacing any existing files.
Revised: * A Windows node takes the ITMS object and uses it to configure registry-wide mirrors. In the following example, specifying a mirror of `quay.io/remote-org/image` to `quay.io/my-org/image` results in the Windows node using that mirror for all images from `quay.io/remote-org`. A such, `quay.io/remote-org/image:tag` uses the `quay.io/my-org/image:tag` image, as expected, but another container using `quay.io/remote-org/different-image:tag`
Original: Also, because Windows nodes configured by the WMCO rely on containerd container runtime, the WMCO ensures that the containerd config files are up-to-date with the registry settings. For new nodes, these files are copied to the instances upon creation. For existing nodes, after activating the mirror registry, the registry controller uses SSH to access each node and copy the generated config files, replacing any existing files.
Revised: For this reason, specify container images using a digest by an IDMS object instead of an ITMS object. Using a digest can prevent the wrong container image from being used, by ensuring that the image the container specifies and the image being pulled have the same digest.
Original: The following YAML file is an example of a `NodeNetworkConfigurationPolicy` manifest to enable the Link Layer Discovery Protocol (LLDP) listener for all ethernet ports in your {product-title} cluster. Devices on a local area network can use LLDP to advertise their identity, capabilities, and neighbor information.
Revised: The following YAML file is an example of a `NodeNetworkConfigurationPolicy` manifest file that enables the Link Layer Discovery Protocol (LLDP) listener for all ethernet ports in your {product-title} cluster. Devices on a local area network can use LLDP to advertise their identity, capabilities, and neighbor's information.
Original: * `spcNoRelabeling`: Disables automatic relabeling of the volume if set to true. You can set this field to true only when `readOnly` is true. When the `readOnly` flag is true, SELinux relabeling of the volume is not possible. This causes the Data Mover backup to fail. Therefore, when you are using the `readOnly` access mode for the CephFS storage class, you must disable relabeling.
Revised: * `spcNoRelabeling`: Disables automatic relabeling of the volume if set to `true`. You can set this field to `true` only when `readOnly` is `true`. When the `readOnly` flag is `true`, SELinux relabeling of the volume is not possible. This causes the Data Mover backup to fail. Therefore, when you are using the `readOnly` access mode for the CephFS storage class, you must disable relabeling.
Original: 3. As the `backupPVC` for `storage-class-1` is `readOnly`, the `spcNoRelabeling` field is set to `true`.
Revised: 3. Because the `backupPVC` for `storage-class-1` is `readOnly`, the `spcNoRelabeling` field is set to `true`.
3. Because the `backupPVC` for `storage-class-1` is `readOnly`, the `spcNoRelabeling` field must be set to `true`.
Original: You can configure the `restorePVC` in the `DataProtectionApplication` (DPA) by using the `ignoreDelayBinding` field. Setting the `ignoreDelayBinding` field to true allows the restore operation to ignore the `WaitForFirstConsumer` binding mode. The data movement restore operation then creates the restore pod and provisions the associated volume to an arbitrary node. 
Revised: You can configure the `restorePVC` in the `DataProtectionApplication` (DPA) object by using the `ignoreDelayBinding` field. Setting the `ignoreDelayBinding` field to `true` allows the restore operation to ignore the `WaitForFirstConsumer` binding mode. The data movement restore operation then creates the restore pod and provisions the associated volume to an arbitrary node.
Original: .Example Data Protection Application
[source,yaml]
----
apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: ts-dpa
  namespace: openshift-adp
spec:
  ...
  configuration:
    nodeAgent:
      enable: true
      uploaderType: kopia
    restorePVC: # <1>
      ignoreDelayBinding: true # <2>
Revised: .Example Data Protection Application
[source,yaml]
apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
name: ts-dpa
namespace: openshift-adp
spec:
#  ...
configuration:
nodeAgent:
enable: true
uploaderType: kopia
restorePVC: # <1>
ignoreDelayBinding: true # <2>
Original: A `backupPVC` is an intermediate `PersistentVolumeClaim` (PVC) to access data during the data movement backup operation. For some storage classes, such as, CephFS, creating a read-only volume from a snapshot results in faster Data Mover backups.
Revised: A backup PVC is an intermediate persistent volume claim (PVC) to access data during the data movement backup operation. For some storage classes, such as, CephFS, creating a read-only volume from a snapshot results in faster Data Mover backups.
Original: A `backupPVC` is an intermediate `PersistentVolumeClaim` (PVC) to access data during the data movement backup operation. For some storage classes, such as, CephFS, creating a read-only volume from a snapshot results in faster Data Mover backups.
Revised: A `backupPVC` is an intermediate `PersistentVolumeClaim` (PVC) to store data during the data movement backup operation. For some storage classes, such as, CephFS, creating a read-only volume from a snapshot results in faster Data Mover backups.
Original: * Verify that OTLP is functioning correctly by going to *Observe* -> *OpenShift Logging* -> *LokiStack* -> *Writes* in the OpenShift web console, and checking *Distributor - Structured Metadata*.
Revised: * To verify that OTLP is functioning correctly, complete the following steps:
.. In the OpenShift web console, click *Observe* -> *OpenShift Logging* -> *LokiStack* -> *Writes*.
.. Check the *Distributor - Structured Metadata* section.
Original: You can use Microsoft Entra ID as an external provider. You must have already configured an Entra ID server before using it as an external provider. See the link:https://learn.microsoft.com/en-us/entra/identity/?culture=en-us&country=us[Microsoft Entra ID documentation] for more information.
Revised: You can use Microsoft Entra ID as an external provider. You must have already configured a Microsoft Entra ID server before using it as an external provider. See the link:https://learn.microsoft.com/en-us/entra/identity/?culture=en-us&country=us[Microsoft Entra ID documentation] for more information.
Original: * See xref:../../installing/installing_bare_metal/ipi/ipi-install-installation-workflow.adoc#configuring-host-network-interfaces-in-the-install-config-yaml-file_ipi-install-installation-workflow[Optional: Configuring host network interfaces in the install-config.yaml file] for details on configuring the NMState syntax.
* See xref:../../scalability_and_performance/managing-bare-metal-hosts.adoc#automatically-scaling-machines-to-available-bare-metal-hosts_managing-bare-metal-hosts[Automatically scaling machines to the number of available bare-metal hosts] for details on automatically scaling machines.
Revised: * xref:../../installing/installing_bare_metal/ipi/ipi-install-installation-workflow.adoc#configuring-host-network-interfaces-in-the-install-config-yaml-file_ipi-install-installation-workflow[Optional: Configuring host network interfaces in the install-config.yaml file]
* xref:../../scalability_and_performance/managing-bare-metal-hosts.adoc#automatically-scaling-machines-to-available-bare-metal-hosts_managing-bare-metal-hosts[Automatically scaling machines to the number of available bare-metal hosts]
Original: * *Creation and modification limitation*: The `ClusterUserDefinedNetwork` CR and the `UserDefinedNetwork` CR cannot be modified after being created.
Revised: * *Default network service access*: A user-defined network pod is isolated from the default network, which means that most default network services are inaccessible. For example, a user-defined network pod cannot access the {product-title} image registry. Because of this limitation, source-to-image builds do not work in a user-defined network namespace. Additionally, other functions do not work, including functions to create applications based on the source code in a Git repository, such as `oc new-app <command>`, and functions to create applications from an {product-title} template that use source-to-image builds. This limitation might also affect other `openshift-*.svc` services.