gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: Use the `LongLifecycle` profile to enable the descheduler on a virtual machine. This is the only descheduler profile currently available for {VirtProductName}. To ensure proper scheduling, create VMs with CPU and memory requests for the expected load.
Revised: The `DevKubeVirtRelieveAndMigrate` profile requires PSI metrics to be enabled on all worker nodes. You can enable this by applying the following `MachineConfig` custom resource (CR):
Original: Use the `LongLifecycle` profile to enable the descheduler on a virtual machine. This is the only descheduler profile currently available for {VirtProductName}. To ensure proper scheduling, create VMs with CPU and memory requests for the expected load.
Revised: `DevKubeVirtRelieveAndMigrate`:: This profile is an enhanced version of the `LongLifeCycle` profile. The `DevKubeVirtRelieveAndMigrate` profile evicts pods from high-cost nodes to reduce overall resource expenses and enable workload migration. It also periodically rebalances workloads to help maintain similar spare capacity across nodes, which supports better handling of sudden workload spikes. Node can experience the following costs:
Original: Use the `LongLifecycle` profile to enable the descheduler on a virtual machine. This is the only descheduler profile currently available for {VirtProductName}. To ensure proper scheduling, create VMs with CPU and memory requests for the expected load.
Revised: You can use this profile with the `SoftTopologyAndDuplicates` profile to also rebalance pods based on soft topology constraints, which can be useful in hosted control plane environments.
Original: [id="dist-tracing-tempo-installing"]
= Installing
:context: dist-tracing-tempo-installing
Revised: For information about installing the deprecated {JaegerShortName}, see xref:../../observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-installing.adoc#dist-tracing-jaeger-installing[Installing] in the {JaegerShortName} documentation.
Original: For removing the deprecated {JaegerShortName}, see xref:../../observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-removing.adoc#dist-tracing-jaeger-removing[Removing] in the {JaegerShortName} documentation.
Revised: For information about removing the deprecated {JaegerShortName}, see xref:../../observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-removing.adoc#dist-tracing-jaeger-removing[Removing] in the {JaegerShortName} documentation.
Original: [id="dist-tracing-tempo-updating"]
:context: dist-tracing-tempo-updating
Revised: For information about upgrading the deprecated {JaegerShortName}, see xref:../../observability/distr_tracing/distr_tracing_jaeger/distr-tracing-jaeger-updating.adoc#dist-tracing-jaeger-updating[Upgrading] in the {JaegerShortName} documentation.
Original: * Previously, after you deleted the `ClusterResourceOverride` custom resource (CR) or you uninstalled the Cluster Resource Override Operator, which also removes the object, the `v1.admission.autoscaling.openshift.io` API service becomes unreachable. This situation impacted other cluster functions, such as other Operator installations from succeeding. With this release, when you delete the Cluster Resource Override Operator, the `v1.admission.autoscaling.openshift.io` API service is also removed. As a result, you can now install other Operators without experiencing installation failures. (link:https://issues.redhat.com/browse/OCPBUGS-55355[*OCPBUGS-55355*])
Revised: * Previously, after you deleted the `ClusterResourceOverride` custom resource (CR) or you uninstalled the Cluster Resource Override Operator, which removes the `ClusterResourceOverride` CR, the `v1.admission.autoscaling.openshift.io` API service becomes unreachable. This situation impacted other cluster functions, such as other Operator installations from succeeding. With this release, when you delete the Cluster Resource Override Operator, the `v1.admission.autoscaling.openshift.io` API service is also removed. As a result, you can now install other Operators without experiencing installation failures. (link:https://issues.redhat.com/browse/OCPBUGS-55355[*OCPBUGS-55355*])
Original: * Previously, during Fibre Channel multipath disk discovery, the Assisted Installer failed to include World Wide Name (WWN) details in the configuration for a cluster. As a result, a Fibre Channel multipath disk could not be matched with a WWN root device. This means that when you specified a `wwn` root device hint in your cluster configuration, the hint excluded all Fibre Channel multipath disks. With this release, the Assisted Installer now includes WWN details in the configuration for a cluster during Fibre Channel multipath disk discovery. If multiple Fibre Channel multipath disks exist, you can now effectively use the `wwn` root device hint to choose a primary disk for your cluster. (link:https://issues.redhat.com/browse/OCPBUGS-55184[*OCPBUGS-55184*]) 
Revised: * Previously, during Fibre Channel multipath disk discovery, the Assisted Installer failed to include World Wide Name (WWN) details in the configuration for a cluster. As a result, a Fibre Channel multipath disk could not be matched with a WWN root device. This meant that when you specified a `wwn` root device hint in your cluster configuration, the hint excluded all Fibre Channel multipath disks. With this release, the Assisted Installer now includes WWN details in the configuration for a cluster during Fibre Channel multipath disk discovery. If multiple Fibre Channel multipath disks exist, you can now effectively use the `wwn` root device hint to choose a primary disk for your cluster. (link:https://issues.redhat.com/browse/OCPBUGS-55184[*OCPBUGS-55184*])
Original: * `Layer2` subnets can be omitted. If omitted, users must configure static IP addresses for the pods. As a consequence, port security only prevents MAC spoofing. For more information, see "Configuring pods with a static IP address".
Revised: * `Localnet` subnets can be omitted. If omitted, users must configure static IP addresses for the pods. As a consequence, port security only prevents MAC spoofing. For more information, see "Configuring pods with a static IP address".
Original: * You have created and configured the Open vSwitch (OVS) bridge mapping to associate the logical OVN-Kubernetes network with the physical node network through the OVS bridge. For more information, see "Configuration for a localnet switched topology".
Revised: * You have created and configured the Open vSwitch (OVS) bridge mapping to associate the logical OVN-Kubernetes network with the physical node network through the OVS bridge. For more information, see **"Configuration for a localnet switched topology"**.
Original: apiVersion: k8s.ovn.org/v1
Revised: apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
creationTimestamp: "2025-05-28T19:30:38Z"
finalizers:
generation: 1
name: cudn-test
resourceVersion: "140936"
uid: 7ff185fa-d852-4196-858a-8903b58f6890
spec:
namespaceSelector:
matchLabels:
"1": "1"
"2": "2"
network:
localnet:
ipam:
lifecycle: Persistent
physicalNetworkName: test
role: Secondary
subnets:
topology: Localnet
status:
conditions:
message: 'NetworkAttachmentDefinition has been created in following namespaces:
[test1, test2]'
reason: NetworkAttachmentDefinitionCreated
status: "True"
type: NetworkCreated
Original: <2> A label query over the set of namespaces that the cluster UDN CR applies to. Uses the standard Kubernetes `MatchLabel` selector. Must not point to `default`, `openshift-*`, or any other system namespaces.
Revised: <2> Define labels to apply the CUDN CR to specific namespaces. You can use the standard Kubernetes `matchLabels` format. Do not target system namespaces like `default`, `openshift-*`, or any other reserved namespaces.
Original: <4> Because the `matchLabels` selector type is used, the CUDN CR is deployed to namespaces that contain both `<label_1_key>=<label_1_value>` and `<label_2_key>=<label_2_value>` labels.
Revised: <4> In this example, the CUDN CR is deployed to namespaces that contain both `<label_1_key>=<label_1_value>` and `<label_2_key>=<label_2_value>` labels.
Original: * `Localnet` subnets can be omitted. If omitted, users must configure static IP addresses for the pods. As a consequence, port security only prevents MAC spoofing. For more information, see "Configuring pods with a static IP address".
Revised: * You can exclude the `Localnet` subnets. In this case, you must configure static IP addresses for the pods. As a consequence, port security only prevents MAC spoofing. For more information, see "Configuring pods with a static IP address".
Original: * The subnets field accepts one or two items. For two items, they must be of a different family. For example, subnets values of `10.100.0.0/16` and `2001:db8::/64`.
Revised: * You can provide one or two subnets. If you specify two, they must belong to different IP families. For example, `10.100.0.0/16` (IPv4) and `2001:db8::/64` (IPv6).
Original: |Specifies a list of CIDRs to be removed from the specified CIDRs in the `subnets` field. The CIDRs in this list must be in range of at least one subnet specified in `subnets`. When omitted no IP address is excluded and all IP addresses specified in `subnets` are subject to assignment. The format should match standard CIDR notation,for example, `10.128.0.0/16`. This field must be omitted if `subnets` is unset or the `ipam.mode` field is set to a value of `Disabled`.
Revised: |Specifies a list of CIDRs to exclude from the CIDRs defined in the subnets field. Each CIDR in this list must fall within the range of at least one subnet specified in the `subnets` field. When omitted, no IP addresses are excluded, and all IP addresses specified in the `subnets` field are subject to assignment. You must use standard CIDR notation. For example, `10.128.0.0/16`. This field must be omitted if the `subnets` field is not set or if the `ipam.mode` field is set to `Disabled`.
Original: |Acceptable values are `Access`. A value of `Access` specifies that the network interface belongs to a single VLAN and all traffic will be labelled with an `id` that is configured in the `spec.network.localnet.vlan.mode.access.id` field. The `id` specifies the VLAN `id` (VID) for access ports. Values must be an integer between 1 and 4094.
Revised: |You can set this field to `Access`.  `Access` specifies that the network interface belongs to a single VLAN. All traffic on the interface is labelled with the VLAN `id` (VID) that is configured in the `spec.network.localnet.vlan.mode.access.id` field.  The VLAN ID must be an integer between `1` and `4094`.
Original: A `Localnet` topology connects the secondary network to the physical underlay. This enables both east-west cluster traffic and access to services running outside the cluster. Connecting to additional services outside the cluster requires the additional configuration of the underlying Open vSwitch (OVS) system on cluster nodes.
Revised: A `Localnet` topology connects the secondary network to the physical underlay. This enables both east-west cluster traffic and access to services running outside the cluster. Connecting to services outside the cluster requires the additional configuration of the underlying Open vSwitch (OVS) system on cluster nodes.
Original: When the `physicalNetworkName` field  points to OVS bridge mapping of a network with reserved IP addresses that are not assigned by OVN-Kubernetes, the specified CIDRs will not be assigned. For example, if `subnets: "10.0.0.0/24"` are set and `excludeSubnets: "10.0.0.200/30" are as well, the following addresses will not be assigned to pods: `10.0.0.201`, `10.0.0.202`.
Revised: When the `physicalNetworkName` field  points to an  Open vSwitch (OVS) bridge mapping of a network with reserved IP addresses that are not assigned by OVN-Kubernetes, the specified CIDRs will not be assigned. For example, if `subnets: "10.0.0.0/24"` is configured and `excludeSubnets: "10.0.0.200/30" is also specified, the following addresses will not be assigned to pods: `10.0.0.201`, `10.0.0.202`.
Original: As of {product-title} 4.18, the Localnet topology is unavailable for use with the `UserDefinedNetwork` and `ClusterUserDefinedNetwork` CRs. It is only available for `NetworkAttachmentDefinition` CRs that leverage secondary networks.
Revised: As of {product-title} 4.19, the `Localnet` topology is generally available for the `ClusterUserDefinedNetwork` CRs and is the preferred method for connecting physical networks to virtual networks. Alternatively, the `NetworkAttachmentDefinition` CR can also be used to create `Localnet` topologies with secondary networks.
Original: A `Localnet` topology connects the secondary network to the physical underlay. This enables both east-west cluster traffic and access to services running outside the cluster. Connecting to additional services outside the cluster requires the additional configuration of the underlying Open vSwitch (OVS) system on cluster nodes.
Revised: A `Localnet` topology connects the secondary network to the physical underlay. This enables both east-west cluster traffic and access to services running outside the cluster. This topology type requires the additional configuration of the underlying Open vSwitch (OVS) system on cluster nodes.
Original: 
:Featurename: Using PolicyGenerator resources with {ztp}
include::snippets/technology-preview.adoc[]

[NOTE]
====
For more information about `PolicyGenerator` resources, see the {rh-rhacm} link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/{rh-rhacm-version}/html/governance/integrate-policy-generator#policy-generator[Policy Generator] documentation.
====
Revised: Using {rh-rhacm} and `{policy-gen-cr}` CRs is the recommended approach for managing policies and deploying them to managed clusters.
Original: Applied `Policy` custom resources (CRs) configure the managed clusters that you provision. You can customize how {rh-rhacm-first} uses `{policy-gen-cr}` CRs to generate the applied `Policy` CRs.
:Featurename: Using PolicyGenerator resources with {ztp}
include::snippets/technology-preview.adoc[]
Revised: Using {rh-rhacm} and `{policy-gen-cr}` CRs is the recommended approach for managing policies and deploying them to managed clusters.
Original: The eBPF Manager is a separate operator that reduces the attack surface, and ensures compliance, security, and conflict prevention by managing all eBPF programs. Network observability uses eBPF Manager to load hooks. This eliminates the need to provide the eBPF Agent with privileged mode or additional Linux capabilities like `CAP_BPF` and `CAP_PERFMON`. The eBPF Manager with network observability is only supported on 64-bit AMD architecture.
Revised: The eBPF Manager is a separate operator that reduces the attack surface, and ensures compliance, security, and conflict prevention by managing all eBPF programs. Network observability can use eBPF Manager to load hooks. This eliminates the need to provide the eBPF Agent with privileged mode or additional Linux capabilities like `CAP_BPF` and `CAP_PERFMON`. The eBPF Manager with network observability is only supported on 64-bit AMD architecture.
Original: . Click *eBPF Manager Operator* -> *All instances* tab.

There should be a `BpfApplication` named `netobserv` and a pair of `BpfProgram` objects, one for Traffic Control (TCx) ingress and another for TCx egress, for each node. There might be more if you enable other eBPF Agent features.
Revised: . Click *eBPF Manager Operator* -> *All instances* tab.

There should be a `BpfApplication` named `netobserv` and a pair of `BpfProgram` objects, one for Traffic Control (TCx) ingress and another for TCx egress, for each node. There might be more if you enable other eBPF Agent features.
Original: The eBPF Manager is a separate Operator that reduces the attack surface, and ensures compliance, security, and conflict prevention by managing all eBPF programs. Network observability can use eBPF Manager to load hooks. This eliminates the need to provide the eBPF Agent with privileged mode or additional Linux capabilities like `CAP_BPF` and `CAP_PERFMON`. The eBPF Manager with network observability is only supported on 64-bit AMD architecture.
Revised: The eBPF Manager Operator reduces the attack surface and ensures compliance, security, and conflict prevention by managing all eBPF programs. Network observability can use eBPF Manager Operator to load hooks. This eliminates the need to provide the eBPF Agent with privileged mode or additional Linux capabilities like `CAP_BPF` and `CAP_PERFMON`. The eBPF Manager Operator with network observability is only supported on 64-bit AMD architecture.
Original: The eBPF Manager Operator reduces the attack surface and ensures compliance, security, and conflict prevention by managing all eBPF programs. Network observability can use eBPF Manager Operator to load hooks. This eliminates the need to provide the eBPF Agent with privileged mode or additional Linux capabilities like `CAP_BPF` and `CAP_PERFMON`. The eBPF Manager Operator with network observability is only supported on 64-bit AMD architecture.
Revised: The eBPF Manager Operator reduces the attack surface and ensures compliance, security, and conflict prevention by managing all eBPF programs. Network observability can use the eBPF Manager Operator to load hooks. As a result, the you no longer need to provide the eBPF Agent with privileged mode or additional Linux capabilities such as `CAP_BPF` and `CAP_PERFMON`. The eBPF Manager Operator with network observability is only supported on 64-bit AMD architecture.
Original: There should be a `BpfApplication` named `netobserv` and a pair of `BpfProgram` objects, one for Traffic Control (TCx) ingress and another for TCx egress, for each node. There might be more if you enable other eBPF Agent features.
Revised: For each node, verify that a `BpfApplication` named `netobserv` and a pair of `BpfProgram` objects, one for Traffic Control (TCx) ingress and another for TCx egress, exist. If you enable other eBPF Agent features, you might have more objects.
Original: xref:configuring-ingress-cluster-traffic-ingress-controller.adoc#nw-ingress-sharding-concept_configuring-ingress-cluster-traffic-ingress-controller[Ingress Controller sharding].
Revised: * xref:configuring-ingress-cluster-traffic-ingress-controller.adoc#nw-ingress-sharding-concept_configuring-ingress-cluster-traffic-ingress-controller[Ingress Controller sharding]
Original: The Gateway API is an open source, community-managed, Kubernetes networking mechanism that focuses on routing within the transport layer, L4, and the application layer, L7, for clusters. There are many implementations of Gateway API by a link:https://gateway-api.sigs.k8s.io/implementations/[variety of vendors].
Revised: The Gateway API is an open source, community-managed, Kubernetes networking mechanism. It focuses on routing within the transport layer, L4, and the application layer, L7, for clusters. A variety of vendors offer many link:https://gateway-api.sigs.k8s.io/implementations/[implementations of Gateway API].
Original: The Gateway API extends the functionality of the Ingress Operator to handle more granular cluster traffic and routing configurations. These capabilities let you create instances of Gateway APIs custom resource definitions (CRDs). For {product-title} clusters, these resources are created by the Ingress Operator and include:
Revised: The Gateway API extends the functionality of the Ingress Operator to handle more granular cluster traffic and routing configurations. With these capabilities, you can create instances of Gateway APIs custom resource definitions (CRDs). For {product-title} clusters, the Ingress Operator creates the following resources:
Original: GatewayClass:: This resource defines a set of Gateways that share a common configuration and behavior. For example, two separate GatewayClasses might be created to distinguish Gateways used for public or private applications.
Revised: GatewayClass:: This resource defines a set of Gateways that share a common configuration and behavior. For example, two separate `GatewayClasses` might be created to distinguish Gateways used for public or private applications.
Original: * Separation of concerns: Gateway API uses a role-based approach to its resources, and more neatly fits into how a large organization has their responsibilities and teams structured. Platform engineers might focus on `GatewayClass` resources, cluster admins might focus on configuring `Gateway` resources, and application developers might focus on routing their services with `HTTPRoute` resources.
Revised: * Separation of concerns: Gateway API uses a role-based approach to its resources, and more neatly fits into how a large organization structures its responsibilities and teams. Platform engineers might focus on `GatewayClass` resources, cluster admins might focus on configuring `Gateway` resources, and application developers might focus on routing their services with `HTTPRoute` resources.
Original: In some situations, the Gateway API provides one or more fields that a given vendor implementation does not support, but that implementation is otherwise compatible in schema with the rest of the fields. These "dead fields" can result in disruption of Ingress workloads, improperly provisioned applications and services, and security related issues. Because {product-title} uses a specific version of Gateway API CRDs, any use of third-party implementations of Gateway API must conform to the {product-title} implementation to ensure that all fields work as expected.
Revised: In some situations, the Gateway API provides one or more fields that a vendor implementation does not support, but that implementation is otherwise compatible in schema with the rest of the fields. These "dead fields" can result in disrupted Ingress workloads, improperly provisioned applications and services, and security-related issues. Because {product-title} uses a specific version of Gateway API CRDs, any use of third-party implementations of Gateway API must conform to the {product-title} implementation to ensure that all fields work as expected.
Original: Any CRDs created within an {product-title} {product-version} cluster will be compatibly versioned and maintained by the Ingress Operator. In the case that CRDs are already present but were not previously managed by the Ingress Operator, the Ingress Operator will check if these configurations are compatible with the Gateway API version supported by {product-title}, and create an admin-gate that requires your acknowledgment of CRD succession.
Revised: Any CRDs created within an {product-title} {product-version} cluster are compatibly versioned and maintained by the Ingress Operator. If CRDs are already present but were not previously managed by the Ingress Operator, the Ingress Operator checks whether these configurations are compatible with the Gateway API version supported by {product-title}, and creates an admin-gate that requires your acknowledgment of CRD succession.
Original: If you are updating your cluster from a previous {product-title} version that contains Gateway API CRDs, you must make changes to these resources such that it exactly matches the version supported by {product-title}. Otherwise, you will not be able to update your cluster. This is because those CRDs were not managed by {product-title}, and could contain functionality that is unsupported by Red{nbsp}Hat.
Revised: If you are updating your cluster from a previous {product-title} version that contains Gateway API CRDs, you must change those resources so that they exactly match the version supported by {product-title}. Otherwise, you cannot update your cluster because those CRDs were not managed by {product-title} and could contain functionality that is unsupported by Red{nbsp}Hat.
Original: Shared gateway:: Routes are served from multiple namespaces or with multiple hostnames. The `Gateway` object filters allow routes from application namespaces using the `spec.listeners.allowedRoutes.namespaces` field.
Revised: Shared gateway:: Routes are served from multiple namespaces or with multiple hostnames. The `Gateway` object filters allow routes from application namespaces by using the `spec.listeners.allowedRoutes.namespaces` field.