gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: [source,yaml]
----
exporters:
  otlp:
    sending_queue:
      storage: file_storage
    endpoint: ${env:OTEL_BACKEND}:4317 <1>
    tls:
      insecure: true
(...)
service:
(...)
  telemetry:
    metrics:
      readers:
        - periodic:
            exporter:
              otlp:
                protocol: http/protobuf
                endpoint: http://${env:OTEL_BACKEND}:4318 <1>
Revised: [source,yaml]
# ...
exporters:
otlp:
sending_queue:
storage: file_storage
endpoint: ${env:OTEL_BACKEND}:4317 <1>
tls:
insecure: true
# ...
service:
# ...
telemetry:
metrics:
readers:
exporter:
otlp:
protocol: http/protobuf
endpoint: http://${env:OTEL_BACKEND}:4318 <1>
# ...
Original: <1> Replace `${env:OTEL_BACKEND}` with the IP address or host name of the remote back end. This IP address will resolve to the local node's host name. An unreachable endpoint is reported in the {microshift-short} service logs.    
Revised: <1> Replace `${env:OTEL_BACKEND}` with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. An unreachable endpoint is reported in the {microshift-short} service logs.
Original: . Restart {microshift-short} Observability by entering the following command:

[source,terminal]
----
$ sudo systemctl restart microshift-observability
----

Each time that you update the `opentelemetry-collector.yaml` file, you must restart {microshift-short} Observability to apply the updates.
Revised: . Each time that you update the `opentelemetry-collector.yaml` file, you must restart {microshift-short} Observability to apply the updates.

Restart {microshift-short} Observability by entering the following command:

[source,terminal]
$ sudo systemctl restart microshift-observability
Original: Compliance Operator scans will report INCONSISTENT on clusters with multi-architecture compute machines whether the control plane uses `aarch64` or `x86` CPUs. This is due to the same rule behaving differently on different architectures. This should only be applicable for node scans, where the Compliance Operator aggregates results from multiple nodes into a single result.
Revised: Compliance Operator scans report `INCONSISTENT` on clusters with multi-architecture compute machines whether the control plane uses `aarch64` or `x86` CPUs. This is due to the same rule behaving differently on different architectures. This should only be applicable for node scans, where the Compliance Operator aggregates results from multiple nodes into a single result.
Original: * Previously, the instructions for rule `ocp4-etcd-unique-ca` did not work for OCP 4.17 and later. With this update, the instructions and actionable steps are corrected. (link:https://issues.redhat.com/browse/OCPBUGS-42350[*OCPBUGS-42350*])
Revised: * Previously, the instructions for rule `ocp4-etcd-unique-ca` did not work for {product-title} 4.17 and later. With this update, the instructions and actionable steps are corrected. (link:https://issues.redhat.com/browse/OCPBUGS-42350[*OCPBUGS-42350*])
Original: * After installing Cluster Logging Operator (CLO) 6.0, users found that the ComplianceCheckResult `ocp4-cis-audit-log-forwarding-enabled` was failing because there was a change in the APIversion of `clusterlogforwarder`. Log collection and forwarding configurations are now specified under the new API, part of the observability.openshift.io API group. (link:https://issues.redhat.com/browse/OCPBUGS-43585[*OCPBUGS-43585*])
Revised: * After installing Cluster Logging Operator (CLO) 6.0, users found that the ComplianceCheckResult `ocp4-cis-audit-log-forwarding-enabled` was failing because there was a change in the APIversion of the `clusterlogforwarder` resource. Log collection and forwarding configurations are now specified under the new API, part of the observability.openshift.io API group. (link:https://issues.redhat.com/browse/OCPBUGS-43585[*OCPBUGS-43585*])
Original: * For previous releases of Compliance Operator, the scans would generate an error log for the reconcile loop on the operator pod. With this release, the Compliance Operator controller logic is more stable. (link:https://issues.redhat.com/browse/OCPBUGS-51267[*OCPBUGS-51267*])
Revised: * For previous releases of Compliance Operator, the scans would generate an error log for the reconcile loop on the Operator pod. With this release, the Compliance Operator controller logic is more stable. (link:https://issues.redhat.com/browse/OCPBUGS-51267[*OCPBUGS-51267*])
Original: * Previously, the rules `file-integrity-exists` or `file-integrity-notification-enabled` would fail on `aarch64` OpenShift clusters. With this update, these rules evaluate as NOT-APPLICABLE on `aarch64` systems. (link:https://issues.redhat.com/browse/OCPBUGS-52884[*OCPBUGS-52884*])
Revised: * Previously, the rules `file-integrity-exists` or `file-integrity-notification-enabled` would fail on `aarch64` {product-title} clusters. With this update, these rules evaluate as `NOT-APPLICABLE` on `aarch64` systems. (link:https://issues.redhat.com/browse/OCPBUGS-52884[*OCPBUGS-52884*])
Original: * Before this release of the Compliance Operator, the rule `kubelet-configure-tls-cipher-suites` failed for the API server ciphers, resulting in `E2E-FAILURE` status. The rule has been updated to check new ciphers from RFC 8446, which are included with OpenShift 4.18. The rule is now being evaluated correctly. (link:https://issues.redhat.com/browse/OCPBUGS-54212[*OCPBUGS-54212*])
Revised: * Before this release of the Compliance Operator, the rule `kubelet-configure-tls-cipher-suites` failed for the API server ciphers, resulting in `E2E-FAILURE` status. The rule has been updated to check new ciphers from RFC 8446, which are included with {product-title} 4.18. The rule is now being evaluated correctly. (link:https://issues.redhat.com/browse/OCPBUGS-54212[*OCPBUGS-54212*])
Original: * Previously, the Compliance Operator platform scan would fail and produce the message `failed to parse Ignition config`. With this release, the Compliance Operator is safe to run on 4.19 clusters, when that version of OpenShift is available to customers. (link:https://issues.redhat.com/browse/OCPBUGS-54403[*OCPBUGS-54403*])
Revised: * Previously, the Compliance Operator platform scan would fail and produce the message `failed to parse Ignition config`. With this release, the Compliance Operator is safe to run on 4.19 clusters, when that version of {product-title} is available to customers. (link:https://issues.redhat.com/browse/OCPBUGS-54403[*OCPBUGS-54403*])
Original: * Before this release of Compliance Operator, several rules were not platform aware, creating unneeded errors. Now that the rules have been properly ported to other architectures, those rules run correctly and users may observe some Compliance Check Results reporting `NOT-APPLICABLE` appropriately, depending on the architecture they are using. (link:https://issues.redhat.com/browse/OCPBUGS-53041[*OCPBUGS-53041*])
Revised: * Before this release of Compliance Operator, several rules were not platform aware, creating unneeded errors. Now that the rules have been properly ported to other architectures, those rules run correctly and users can observe some Compliance Check Results reporting `NOT-APPLICABLE` appropriately, depending on the architecture they are using. (link:https://issues.redhat.com/browse/OCPBUGS-53041[*OCPBUGS-53041*])
Original: * Previously, rule `file-groupowner-ovs-conf-db-hugetlbf` would fail unexpectedly. With this release, the rule fails only when this is the needed result. (link:http://issues.redhat.com/browse/OCPBUGS-55180[*OCPBUGS-55190*])
Revised: * Previously, the rule `file-groupowner-ovs-conf-db-hugetlbf` would fail unexpectedly. With this release, the rule fails only when this is the needed result. (link:http://issues.redhat.com/browse/OCPBUGS-55180[*OCPBUGS-55190*])
Original: {product-title} release {product-version}.39 is now available. The list of bug fixes that are included in the update is documented in the link:https://access.redhat.com/errata/RHSA-2025:4008[RHSA-2025:4008] advisory. The RPM packages that are included in the update are provided by the link:https://access.redhat.com/errata/RHBA-2025:4010[RHBA-2025:4010] advisory.
Revised: Issued: 23 April 2025
Original: * Previously, the error message "unable to read image" displayed when building the agent ISO in a disconnected setup even though the image was created. This was due to the `ImageContentSourcePolicy` (ICSP) not being checked. With this release, the error message no longer displays. (link:https://issues.redhat.com/browse/OCPBUGS-53378[OCPBUGS-53378])
Revised: * Previously, when the `openshift-install agent create pxe-files` command was run, the command created temporary directories in `/tmp/agent` and the command did not remove these directories upon completion. With this release, the command now removes the directories when the command nears completion, so manual deletion of directories is not necessary. (link:https://issues.redhat.com/browse/OCPBUGS-54345[OCPBUGS-54345])
Original: * Previously, the cluster autoscaler stopped scaling because a machine failed in a machine set. This situation happened because of inaccuracies in the way the cluster autoscaler counts machines in various non-running phases. With this release, the inaccuracies have been fixed so that the cluster autoscaler has a more accurate count. (link:https://issues.redhat.com/browse/OCPBUGS-54325[OCPBUGS-54325]) 
Revised: * Previously, the error message "unable to read image" displayed when building the agent ISO in a disconnected setup even though the image was created. This was due to the `ImageContentSourcePolicy` (ICSP) not being checked. With this release, the error message no longer displays. (link:https://issues.redhat.com/browse/OCPBUGS-54327[OCPBUGS-54327])
Original:  * Previously, an update to the {ibm-cloud-name} Cloud Internet Services (CIS) implementation impacted the upstream Terraform plugin. If there was an attempt to create an external-facing cluster on {ibm-cloud-name}, the following error occurred:
Revised: * Previously, the cluster autoscaler stopped scaling because a machine failed in a machine set. This situation happened because of inaccuracies in the way the cluster autoscaler counts machines in various non-running phases. With this release, the inaccuracies have been fixed so that the cluster autoscaler has a more accurate count. (link:https://issues.redhat.com/browse/OCPBUGS-54326[OCPBUGS-54326])
Original: * Previously, a User Datagram Protocol (UDP) packet that was larger than the maximum transmission unit (MTU) value set for the cluster could not be sent to the endpoint of the packet by using a service. With this release, the pod IP address is used instead of the service IP address regardless of the packet size, so that the UDP packet can be sent to the endpoint. (link:https://issues.redhat.com/browse/OCPBUGS-50581[OCPBUGS-50581]) 
Revised: * Previously, the Operator Marketplace and the {olm-first} used an older version of the `pod-security.kubernetes.io/` label. With this release, the namespace where the Operator Marketplace is deployed now uses the Pod Security Admission (PSA) label marked as `latest`. (link:https://issues.redhat.com/browse/OCPBUGS-53283[OCPBUGS-53283])
Original:  * IPsec is not supported on {op-system-base-full} compute nodes because of a `libreswan` incompatiblility issue between a host and an `ovn-ipsec` container that exists in each compute node. (link:https://issues.redhat.com/browse/OCPBUGS-52949[OCPBUGS-52949]). 
Revised: * IPsec is not supported on {op-system-base-full} compute nodes because of a `libreswan` incompatiblility issue between a host and an `ovn-ipsec` container that exists in each compute node. (link:https://issues.redhat.com/browse/OCPBUGS-52952[OCPBUGS-52952]).
Original: * Previously, when the `openshift-install agent create pxe-files` command was run, the command created temporary directories in `/tmp/agent` and the command did not remove these directories upon completion. With this release, the command now removes the directories when the command nears completion, so manual deletion of directories is not necessary. (link:https://issues.redhat.com/browse/OCPBUGS-54327[OCPBUGS-54327])
Revised: * Previously, when the `openshift-install agent create pxe-files` command was run, the command created temporary directories in `/tmp/agent` and the command did not remove these directories upon completion. With this release, the command now removes the directories when the command nears completion, so manual deletion of directories is not necessary. (link:https://issues.redhat.com/browse/OCPBUGS-54345[OCPBUGS-54345])
Original:  * IPsec is not supported on {op-system-base-full} compute nodes because of a `libreswan` incompatiblility issue between a host and an `ovn-ipsec` container that exists in each compute node. (link:https://issues.redhat.com/browse/OCPBUGS-42952[OCPBUGS-42952]). 
Revised: * IPsec is not supported on {op-system-base-full} compute nodes because of a `libreswan` incompatiblility issue between a host and an `ovn-ipsec` container that exists in each compute node. (link:https://issues.redhat.com/browse/OCPBUGS-52952[OCPBUGS-52952]).
Original: The MCS CA appears in the cluster as a config map in the `kube-system` namespace, `root-ca` object, with `ca.crt` key.  The private key is not stored in the cluster and is discarded after the installation completes.
The MCS cert appears in the cluster as a secret in the `openshift-machine-config-operator` namespace and `machine-config-server-tls` object with the `tls.crt` and `tls.key` keys.
The MCS CA is valid for 10 years.
Revised: The MCS CA and MCS cert are valid for 10 years and are automatically rotated by the MCO at 8 years.
Original: The MCS CA appears in the cluster as a config map in the `kube-system` namespace, `root-ca` object, with `ca.crt` key.  The private key is not stored in the cluster and is discarded after the installation completes.
Revised: The MCS CA bundle appears in the cluster as a config map in the `openshift-machine-config-operator` namespace called `machine-config-server-ca` and the MCS CA signing key appears as a secret in the `openshift-machine-config-operator` namespace, and is also called `machine-config-server-ca`. The config map contains the `ca.crt` key. The private key is not stored in the cluster and is discarded after the installation completes. The config map is used in the following ways:
Original: The MCS CA and MCS cert are valid for 10 years and are automatically rotated by the MCO at approximately 8 years. Upon installation or upgrade to {product-title} {product-version}, the CA signing key is not retained. As a result, the CA bundle is immediately considered expired when the MCO certificate controller comes up. This expiration causes an immediate certificate rotation, even if the cluster is not 10 years old. After that point, the next rotation takes place at the standard 8 year period.
Revised: The MCS CA and MCS cert are valid for 10 years and are automatically rotated by the MCO at approximately 8 years. Upon upgrade to {product-title} {product-version}, the CA signing key is not present. As a result, the CA bundle is immediately considered expired when the MCO certificate controller comes up. This expiration causes an immediate certificate rotation, even if the cluster is not 10 years old. After that point, the next rotation takes place at the standard 8 year period.
Original: action: Accept  <1>
cidr: 172.210.150.1/24 <2>
protocol: SCTP
direction: Ingress
destPortRange: 80-100
peerIP: 10.10.10.10
enable: true    <3>
<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
<2> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
Revised: <1> You must set `spec.agent.ebpf.privileged` to `true` for packet drop feature.
Original: ebpf:
action: Accept  <1>
cidr: 0.0.0.0/0 <2>
protocol: TCP
direction: Egress
sourcePort: 100
peerIP: 192.168.127.12 <3>
enable: true    <4>
----
<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
<3> See flows after `peerIP` is configured with `192.168.127.12`.
<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
Revised: <2> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
Original: ebpf:
action: Accept  <1>
cidr: 0.0.0.0/0 <2>
protocol: TCP
direction: Egress
sourcePort: 100
peerIP: 192.168.127.12 <3>
enable: true    <4>
----
<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
<3> See flows after `peerIP` is configured with `192.168.127.12`.
<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
Revised: <1> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable eBPF flow filtering.
Original: action: Accept  <1>
cidr: 172.210.150.1/24 <2>
protocol: SCTP
direction: Ingress
destPortRange: 80-100
peerIP: 10.10.10.10
enable: true    <3>
<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
<2> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
Revised: <2> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable eBPF flow filtering.
Original: You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be recorded. Then only the packets that match the filter are cached and the rest are not cached.
Revised: You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be captured. Then only the packets that match the filter are captured and the rest are dropped.
Original: ebpf:
flowFilter:
action: Accept  <1>
cidr: 0.0.0.0/0 <2>
protocol: TCP
direction: Egress
sourcePort: 100
peerIP: 192.168.127.12 <3>
enable: true    <4>
----
<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
<3> See flows after `peerIP` is configured with `192.168.127.12`.
<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
====
Revised: pktDrops: true
Original: agent:
type: eBPF
ebpf:
flowFilter:
action: Accept  <1>
cidr: 172.210.150.1/24 <2>
protocol: SCTP
direction: Ingress
destPortRange: 80-100
peerIP: 10.10.10.10
enable: true    <3>
<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
<2> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
====
Revised: <3> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
Original: agent:
type: eBPF
ebpf:
flowFilter:
action: Accept  <1>
cidr: 172.210.150.1/24 <2>
protocol: SCTP
direction: Ingress
destPortRange: 80-100
peerIP: 10.10.10.10
enable: true    <3>
<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
<2> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
====
Revised: By default, all other flows are rejected.
Original: ebpf:
flowFilter:
action: Accept  <1>
cidr: 0.0.0.0/0 <2>
protocol: TCP
direction: Egress
sourcePort: 100
peerIP: 192.168.127.12 <3>
enable: true    <4>
----
<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
<3> See flows after `peerIP` is configured with `192.168.127.12`.
<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
====
Revised: By default, all other flows are rejected.
Original: ebpf:
flowFilter:
action: Accept  <1>
cidr: 0.0.0.0/0 <2>
protocol: TCP
direction: Egress
sourcePort: 100
peerIP: 192.168.127.12 <3>
enable: true    <4>
----
<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
<3> See flows after `peerIP` is configured with `192.168.127.12`.
<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
====
Revised: pktDrops: true <5>
Original: ebpf:
flowFilter:
action: Accept  <1>
cidr: 0.0.0.0/0 <2>
protocol: TCP
direction: Egress
sourcePort: 100
peerIP: 192.168.127.12 <3>
enable: true    <4>
----
<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
<3> See flows after `peerIP` is configured with `192.168.127.12`.
<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
====
Revised: <5> Set `pktDrops` to `true` to filter flows containing drops
Original: ebpf:
action: Accept  <1>
cidr: 0.0.0.0/0 <2>
protocol: TCP
direction: Egress
sourcePort: 100
peerIP: 192.168.127.12 <3>
enable: true    <4>
----
<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
<3> See flows after `peerIP` is configured with `192.168.127.12`.
<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
====
Revised: cidr: 172.30.0.0/16
Original: ebpf:
action: Accept  <1>
cidr: 0.0.0.0/0 <2>
protocol: TCP
direction: Egress
sourcePort: 100
peerIP: 192.168.127.12 <3>
enable: true    <4>
----
<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
<3> See flows after `peerIP` is configured with `192.168.127.12`.
<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
====
Revised: pktDrops: true <5>
Original: action: Accept  <1>
cidr: 172.210.150.1/24 <2>
protocol: SCTP
direction: Ingress
destPortRange: 80-100
peerIP: 10.10.10.10
enable: true    <3>
<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
<2> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
Revised: <2> The required `action` parameter specifies the action that is taken for the flow filter rule. Valid values are `Accept` or `Reject`.