gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: An OVN-Kubernetes secondary network is compatible with the xref:../../networking/multiple_networks/secondary_networks/configuring-multi-network-policy.adoc#compatibility-with-multi-network-policy_configuring-additional-network[multi-network policy API] which provides the `MultiNetworkPolicy` custom resource definition (CRD) to control traffic flow to and from VMs. You can use the `ipBlock` attribute to define network policy ingress and egress rules for specific CIDR blocks.
Revised: An OVN-Kubernetes secondary network is compatible with the xref:../../networking/multiple_networks/secondary_networks/configuring-multi-network-policy.adoc#compatibility-with-multi-network-policy_configuring-additional-network[multi-network policy API] which provides the `MultiNetworkPolicy` custom resource definition (CRD) to control traffic flow to and from VMs. You must use the `ipBlock` attribute to define network policy ingress and egress rules for specific CIDR blocks. Using pod or namespace selector policy peers are not supported.
Original:     localnet:
        role: Secondary # <6>
        physicalNetworkName: tenantblue # <7>
        subnets: ["192.168.100.0/24", "2001:dbb::/64"]
        excludeSubnets: ["192.168.100.1/32", "2001:dbb::0/128"]
Revised: localnet:
role: Secondary # <6>
physicalNetworkName: tenantblue # <7>
ipam:
mode: Disabled
Original: <6> Specifies if the UDN is primary or secondary. {VirtProductName} only supports the `Primary` role. This means that the UDN acts as the primary network for the VM and all default traffic passes through this network.
Revised: <6> Specifies whether the UDN is primary or secondary. The `Primary` role means that the UDN acts as the primary network for the VM and all default traffic passes through this network.
Original: <4> Specifies if the UDN is primary or secondary. {VirtProductName} only supports the `Primary` role. This means that the UDN acts as the primary network for the VM and all default traffic passes through this network.
Revised: <4> Specifies whether the UDN is primary or secondary. The `Primary` role means that the UDN acts as the primary network for the VM and all default traffic passes through this network.
Original: <3> The name of the additional network from which traffic is forwarded to the OVS bridge. This attribute must match the value of the `spec.config.name` field of the `NetworkAttachmentDefinition` object that defines the OVN-Kubernetes additional network.
Revised: <3> The name of the additional network from which traffic is forwarded to the OVS bridge. This attribute must match the value of the `spec.config.name` field of the `NetworkAttachmentDefinition` object that defines the OVN-Kubernetes additional network. This example uses the name `tenantblue`.
Original: <2> The set of namespaces that the cluster UDN applies to. The namespace selector must not point to `default`, an `openshift-*` namespace, or any global namespaces that are defined by the Cluster Network Operator (CNO).
Revised: <2> The set of namespaces that the cluster UDN applies to. The namespace selector must not point to the following values: `default`; an `openshift-*` namespace; or any global namespaces that are defined by the Cluster Network Operator (CNO).
Original: <7> The name of the OVN bridge mapping that is configured on the node. This value must match the `spec.desiredState.ovn.bridge-mappings.localnet` field in the `NodeNetworkConfigurationPolicy` manifest that you previously created. This ensures that you are bridging to the intended segment of your physical network.
Revised: <7> The name of the OVN-Kubernetes bridge mapping that is configured on the node. This value must match the `spec.desiredState.ovn.bridge-mappings.localnet` field in the `NodeNetworkConfigurationPolicy` manifest that you previously created. This ensures that you are bridging to the intended segment of your physical network.
Original: You can connect a virtual machine (VM) to an OVN-Kubernetes secondary network. {VirtProductName} supports the `layer2` and `localnet` topologies for OVN-Kubernetes.
* A `layer2` topology connects workloads by a cluster-wide logical switch. The OVN-Kubernetes Container Network Interface (CNI) plugin uses the Geneve (Generic Network Virtualization Encapsulation) protocol to create an overlay network between nodes. You can use this overlay network to connect VMs on different nodes, without having to configure any additional physical networking infrastructure.

* 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, but it requires additional configuration of the underlying Open vSwitch (OVS) system on cluster nodes.
An OVN-Kubernetes secondary network is compatible with the xref:../../networking/multiple_networks/secondary_networks/configuring-multi-network-policy.adoc#compatibility-with-multi-network-policy_configuring-additional-network[multi-network policy API] which provides the `MultiNetworkPolicy` custom resource definition (CRD) to control traffic flow to and from VMs. You can use the `ipBlock` attribute to define network policy ingress and egress rules for specific CIDR blocks.
To configure an OVN-Kubernetes secondary network and attach a VM to that network, perform the following steps:
. xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#virt-connecting-vm-to-ovn-secondary-network[Configure an OVN-Kubernetes secondary network] by creating a network attachment definition (NAD).
ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+
[NOTE]
====
For `localnet` topology, you must xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-ovnk.adoc#configuration-localnet-switched-topology_configuring-additional-network-ovnk[configure an OVS bridge] by creating a `NodeNetworkConfigurationPolicy` object before creating the NAD.
====
endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
. xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#attaching-vm-to-ovn-secondary-nw[Connect the VM to the OVN-Kubernetes secondary network] by adding the network details to the VM specification.
== Creating an OVN-Kubernetes NAD
You can create an OVN-Kubernetes network attachment definition (NAD) by using the {product-title} web console or the CLI.
Revised: You can create an OVN-Kubernetes network attachment definition (NAD) for the layer 2 network topology by using the {product-title} web console or the CLI.
Original: You can connect a virtual machine (VM) to an OVN-Kubernetes secondary network. {VirtProductName} supports the `layer2` and `localnet` topologies for OVN-Kubernetes.
* A `layer2` topology connects workloads by a cluster-wide logical switch. The OVN-Kubernetes Container Network Interface (CNI) plugin uses the Geneve (Generic Network Virtualization Encapsulation) protocol to create an overlay network between nodes. You can use this overlay network to connect VMs on different nodes, without having to configure any additional physical networking infrastructure.

* 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, but it requires additional configuration of the underlying Open vSwitch (OVS) system on cluster nodes.
An OVN-Kubernetes secondary network is compatible with the xref:../../networking/multiple_networks/secondary_networks/configuring-multi-network-policy.adoc#compatibility-with-multi-network-policy_configuring-additional-network[multi-network policy API] which provides the `MultiNetworkPolicy` custom resource definition (CRD) to control traffic flow to and from VMs. You can use the `ipBlock` attribute to define network policy ingress and egress rules for specific CIDR blocks.
To configure an OVN-Kubernetes secondary network and attach a VM to that network, perform the following steps:
. xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#virt-connecting-vm-to-ovn-secondary-network[Configure an OVN-Kubernetes secondary network] by creating a network attachment definition (NAD).
ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+
[NOTE]
====
For `localnet` topology, you must xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-ovnk.adoc#configuration-localnet-switched-topology_configuring-additional-network-ovnk[configure an OVS bridge] by creating a `NodeNetworkConfigurationPolicy` object before creating the NAD.
====
endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
. xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#attaching-vm-to-ovn-secondary-nw[Connect the VM to the OVN-Kubernetes secondary network] by adding the network details to the VM specification.
Revised: . xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#attaching-vm-to-ovn-secondary-nw[Connect the VM to the OVN-Kubernetes layer 2 secondary network].
Original: You can connect a virtual machine (VM) to an OVN-Kubernetes localnet secondary network by using the CLI. Cluster administrators can use the `ClusterUserDefinedNetwork` (CUDN) custom resource definition (CRD) to create a shared OVN network across multiple namespaces.
Revised: You can connect a virtual machine (VM) to an OVN-Kubernetes localnet secondary network by using the CLI. Cluster administrators can use the `ClusterUserDefinedNetwork` (CUDN) custom resource definition (CRD) to create a shared OVN-Kubernetes network across multiple namespaces.
Original: An OVN-Kubernetes secondary network is compatible with the xref:../../networking/multiple_networks/secondary_networks/configuring-multi-network-policy.adoc#compatibility-with-multi-network-policy_configuring-additional-network[multi-network policy API] which provides the `MultiNetworkPolicy` custom resource definition (CRD) to control traffic flow to and from VMs. You must use the `ipBlock` attribute to define network policy ingress and egress rules for specific CIDR blocks. Using pod or namespace selector policy peers is not supported.
Revised: An OVN-Kubernetes secondary network is compatible with the xref:../../networking/multiple_networks/secondary_networks/configuring-multi-network-policy.adoc#compatibility-with-multi-network-policy_configuring-additional-network[multi-network policy API] which provides the `MultiNetworkPolicy` custom resource definition (CRD) to control traffic flow to and from VMs.

[IMPORTANT]
====
You must use the `ipBlock` attribute to define network policy ingress and egress rules for specific CIDR blocks. Using pod or namespace selector policy peers is not supported.
Original: 
You can connect a virtual machine (VM) to a user-defined network (UDN) on the VM’s primary interface. The primary user-defined network replaces the default pod network to connect pods and VMs in selected namespaces. Cluster administrators can configure a primary `UserDefinedNetwork` CRD to create a tenant network that isolates the tenant namespace from other namespaces without requiring network policies. Additionally, cluster administrators can use the `ClusterUserDefinedNetwork` CRD to create a shared OVN `layer2` network across multiple namespaces.
Revised: You can connect a virtual machine (VM) to a user-defined network (UDN) on the primary interface of the VM. The primary UDN replaces the default pod network that connect pods and VMs in selected namespaces.
Original: 
You can connect a virtual machine (VM) to a user-defined network (UDN) on the VM’s primary interface. The primary user-defined network replaces the default pod network to connect pods and VMs in selected namespaces. Cluster administrators can configure a primary `UserDefinedNetwork` CRD to create a tenant network that isolates the tenant namespace from other namespaces without requiring network policies. Additionally, cluster administrators can use the `ClusterUserDefinedNetwork` CRD to create a shared OVN `layer2` network across multiple namespaces.
Revised: Cluster administrators can configure a primary `UserDefinedNetwork` CRD to create a tenant network that isolates the tenant namespace from other namespaces without requiring network policies. Additionally, cluster administrators can use the `ClusterUserDefinedNetwork` CRD to create a shared OVN layer 2 network across multiple namespaces.
Original: * {ibm-z-name} running with {product-title} 4.19, and {oadp-version-1-5} was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running {ibm-z-name} with {product-title} 4.19, and {oadp-version-1-5} against all S3 backup location targets, which are not AWS, as well.
Revised: * {ibm-z-name} running with {product-title} 4.19 and {oadp-short} {oadp-version-1-5} was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running {ibm-z-name} with {product-title} 4.19 and {oadp-short} {oadp-version-1-5} against all S3 backup location targets, which are not AWS, as well.
Original: * {ibm-power-name} running with {product-title} 4.19, and {oadp-short} {oadp-version-1-5} was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running {ibm-power-name} with {product-title} 4.19, and {oadp-short} {oadp-version-1-5} against all S3 backup location targets, which are not AWS, as well.
Revised: * {ibm-power-name} running with {product-title} 4.19 and {oadp-short} {oadp-version-1-5} was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running {ibm-power-name} with {product-title} 4.19 and {oadp-short} {oadp-version-1-5} against all S3 backup location targets, which are not AWS, as well.
Original: |Release of 1.6
|Release of 1.7
a|

EUS must be on OCP 4.20
a|
EUS Term 2 must be on OCP 4.20

Revised: // |Release of 1.6
// |Release of 1.7
// a|
//
// EUS must be on OCP 4.20
// a|
// EUS Term 2 must be on OCP 4.20
//
Original: * Before this update, the RBAC ConfigMap's scope was configured with `\\[groups,email\\]` but the corresponding `Spec.RBAC.Scopes` remained unchanged. This discrepancy led to conflicts during ConfigMap synchronization, specifically when transitioning to Keycloak SSO and modifying the Argo CD configuration. With this update, a new mechanism is implemented in the {gitops-title} Operator to maintain the existing RBAC scope configuration within the RBAC ConfigMap when upgrading to Keycloak SSO. link:https://issues.redhat.com/browse/GITOPS-5977[GITOPS-5977]
Revised: * Before this update, the RBAC ConfigMap's scope was configured with `\\[groups,email\\]` but the corresponding `Spec.RBAC.Scopes` remained unchanged. This discrepancy led to conflicts during ConfigMap synchronization when transitioning to Keycloak SSO. With this update, a new mechanism is implemented in the {gitops-title} Operator to maintain the existing RBAC scope configuration within the RBAC ConfigMap when upgrading to Keycloak SSO. link:https://issues.redhat.com/browse/GITOPS-5977[GITOPS-5977]
Original: * Before this update, the RBAC ConfigMap scope was configured with `\\[groups,email\\]` but the corresponding `Spec.RBAC.Scopes` remained unchanged. This discrepancy led to conflicts during ConfigMap synchronization when transitioning to Keycloak SSO. With this update, a new mechanism is implemented in the {gitops-title} Operator to maintain the existing RBAC scope configuration within the RBAC ConfigMap when upgrading to Keycloak SSO. link:https://issues.redhat.com/browse/GITOPS-5977[GITOPS-5977]
Revised: * Before this update, the scope configuration in the RBAC ConfigMap `argocd-rbac-cm` was configured with `'[groups,email]'` without the corresponding change in `.spec.rbac.scopes`. This discrepancy led to conflicts during ConfigMap synchronization when transitioning to Keycloak SSO. With this update, a new mechanism is implemented in the {gitops-title} Operator to maintain the existing RBAC scope configuration within the RBAC ConfigMap  `argocd-rbac-cm` when switching to Keycloak SSO. link:https://issues.redhat.com/browse/GITOPS-5977[GITOPS-5977]
Original: * Before this update, the scope configuration in the RBAC ConfigMap `argocd-rbac-cm` was configured with `'[groups,email]'` without the corresponding change in `.spec.rbac.scopes`. This discrepancy led to conflicts during ConfigMap synchronization when transitioning to Keycloak SSO. With this update, a new mechanism is implemented in the {gitops-title} Operator to maintain the existing RBAC scope configuration within the RBAC ConfigMap  `argocd-rbac-cm` when upgrading to Keycloak SSO. link:https://issues.redhat.com/browse/GITOPS-5977[GITOPS-5977]
Revised: * Before this update, the scope configuration in the RBAC `argocd-rbac-cm` config map was configured with `'[groups,email]'` without the corresponding change in `.spec.rbac.scopes`. This discrepancy led to conflicts during config map synchronization when transitioning to Keycloak SSO. With this update, a new mechanism is implemented in the {gitops-title} Operator to maintain the existing RBAC scope configuration within the RBAC `argocd-rbac-cm` config map when upgrading to Keycloak SSO. link:https://issues.redhat.com/browse/GITOPS-5977[GITOPS-5977]
Original: {gitops-title} 1.16.0 is now available on {OCP} 4.12, 4.13, 4.14, 4.15, 4.16, 4.17, and 4.18.
Revised: {gitops-title} 1.16.1 is now available on {OCP} 4.12, 4.13, 4.14, 4.15, 4.16, 4.17, and 4.18.
Original: * Before this update, merging data from the `message` field into the root of a Syslog log event caused the log event to be inconsistent with the ViaQ data model. The inconsistency could lead to overwritten system information, data duplication, or event corruption. This update revises Syslog parsing and merging for the Syslog output to align with other output types, resolving this inconsistency. (link:https://issues.redhat.com/browse/LOG-7183[LOG-7183])
Revised: * Before this update, merging data from the `message` field into the root of a Syslog log event caused inconsistencies with the ViaQ data model. These inconsistencies could overwrite system information, duplicate data, or corrupt the log event. With this update, Syslog parsing and merging aligns with other output types, resolving the inconsistency. (link:https://issues.redhat.com/browse/LOG-7183[LOG-7183])
Original: * Before this update, log forwarding failed if you configured a cluster-wide proxy with a URL containing a username with an encoded "@" symbol; for example "user%40name". This update resolves the issue by adding correct support for URL-encoded values in proxy configurations. (link:https://issues.redhat.com/browse/LOG-7186[LOG-7186])
Revised: * Before this update, log forwarding failed when the cluster-wide proxy configuration included a URL with a username containing an encoded `@` symbol; for example, `user%40name`. With this update, the system support the URL-encoded values in proxy configurations. (link:https://issues.redhat.com/browse/LOG-7186[LOG-7186])
Original: * Before this update, merging data from the `message` field into the root of a Syslog log event caused the log event to be inconsistent with the ViaQ data model. The inconsistency could lead to overwritten system information, data duplication, or event corruption. This update revises Syslog parsing and merging for the Syslog output to align with other output types, resolving this inconsistency. (link:https://issues.redhat.com/browse/LOG-7183[LOG-7183])
Revised: * Before this update, merging data from the `message` field into the root of a Syslog log event caused  inconsistencies with the ViaQ data model. These inconsistencies could overwrite system information, duplicate data, or corrupt the log event. This update makes Syslog parsing and merging consistent with the other output types and resolves the issue.  (link:https://issues.redhat.com/browse/LOG-7183[LOG-7183])
Original: * Before this update, log forwarding failed if you configured a cluster-wide proxy with a URL containing a username with an encoded "@" symbol; for example "user%40name". This update resolves the issue by adding correct support for URL-encoded values in proxy configurations. (link:https://issues.redhat.com/browse/LOG-7186[LOG-7186])
Revised: * Before this update, log forwarding failed when the cluster-wide proxy configuration included a URL with a username containing an encoded `@` symbol; for example, `user%40name`. This update adds the correct support for URL-encoded values in proxy configurations and resolves the issue. (link:https://issues.redhat.com/browse/LOG-7186[LOG-7186])
Original: * Before this update, log forwarding failed if you configured a cluster-wide proxy with a URL containing a username with an encoded "@" symbol; for example "user%40name". This update resolves the issue by adding correct support for URL-encoded values in proxy configurations. (link:https://issues.redhat.com/browse/LOG-7188[LOG-7188])
Revised: * Before this update, log forwarding failed if you configured a cluster-wide proxy with a URL containing a username with an encoded at sign (`@`); for example `user%40name`. This update resolves the issue by adding correct support for URL-encoded values in proxy configurations. (link:https://issues.redhat.com/browse/LOG-7188[LOG-7188])
Original: You can use a MAC address to identify a network interface instead of relying on the name of the network interface. Every network interface has a unique MAC address, making a MAC address an ideal candidate for identifying a network interface. Consider that a network interface name can change for various reasons, such as an operating system configuration change. 
Revised: You can use a MAC address to identify a network interface instead of using the name of the network interface. A network interface name can change for various reasons, such as an operating system configuration change. However, every network interface has a unique MAC address that does not change. This means that using a MAC address is a more permanent way to identify a specific network interface.
Original: Supported values for the `identifier` parameter include `name`, the default value, and `mac-address`. The `name` value applies a configuration to an interface that holds a specified interface name. The `mac-address` value for `identifier` indicates that a MAC address represents the identifier for a network interface and requires that you set a MAC address value for the `mac-address` parameter. 
Revised: Supported values for the `identifier` parameter include the default `name` value and the value `mac-address`. The `name` value applies a configuration to an interface that holds a specified interface name.

Using a `mac-address` value for the `identifier` parameter indicates that a MAC address is the identifier for the network interface. If you set the `identifier` value to `mac-address`, you must enter a specific MAC address in the following `mac-address` parameter field.
Original: //[id="microshift-4-19-ingress-controller-two-config_{context}"]
//==== Control ingress for your use case with additional parameters
//add phase 2 ingress control parameters announcement here
Revised: With this release, the `ingress.certificate.Secret`,`ingress.clientTLS`, `ingress.routeAdmissionPolicy`, and `ingress.tlsSecurityProfile` parameters are added to the YAML configuration file for {microshift-short}. These parameters specify security settings for the ingress controller. For more information, see xref:../microshift_configuring/microshift-ingress-controller.adoc#microshift-ingress-controller[Using ingress control for a {microshift-short} cluster].