<commit_before>// Module included in the following assemblies:
//
// * networking/ovn_kubernetes_network_provider/migrate-from-openshift-sdn.adoc

[id="nw-ovn-kubernetes-migration-about_{context}"]
= Migration to the OVN-Kubernetes network provider

Migrating to the OVN-Kubernetes Container Network Interface (CNI) cluster network provider is a manual process that includes some downtime during which your cluster is unreachable. Although a rollback procedure is provided, the migration is intended to be a one-way process.


A migration to the OVN-Kubernetes cluster network provider is supported on the following platforms:

* Bare metal hardware
* Amazon Web Services (AWS)
* Google Cloud Platform (GCP)
* Microsoft Azure
* {rh-openstack-first}
* {rh-virtualization-first}
* VMware vSphere

[id="considerations-migrating-ovn-kubernetes-network-provider_{context}"]
== Considerations for migrating to the OVN-Kubernetes network provider

The subnets assigned to nodes and the IP addresses assigned to individual pods are not preserved during the migration.

While the OVN-Kubernetes network provider implements many of the capabilities present in the OpenShift SDN network provider, the configuration is not the same.

* If your cluster uses any of the following OpenShift SDN capabilities, you must manually configure the same capability in OVN-Kubernetes:
+
--
* Namespace isolation
* Egress IP addresses
* Egress network policies
* Egress router pods
* Multicast
--

* If your cluster uses any part of the `172.16.58.3/16` IP address range, you cannot migrate to OVN-Kubernetes because it uses this IP address range internally.

The following sections highlight the differences in configuration between the aforementioned capabilities in OVN-Kubernetes and OpenShift SDN.

[discrete]
[id="namespace-isolation_{context}"]
=== Namespace isolation

OVN-Kubernetes supports only the network policy isolation mode.

[IMPORTANT]
====
If your cluster uses OpenShift SDN configured in either the multitenant or subnet isolation modes, you cannot migrate to the OVN-Kubernetes network provider.
====

[discrete]
[id="egress-ip-addresses_{context}"]
=== Egress IP addresses

The differences in configuring an egress IP address between OVN-Kubernetes and OpenShift SDN is described in the following table:

.Differences in egress IP address configuration
[cols="1a,1a",options="header"]
|===
|OVN-Kubernetes|OpenShift SDN

|
* Create an `EgressIPs` object
* Add an annotation on a `Node` object

|
* Patch a `NetNamespace` object
* Patch a `HostSubnet` object
|===

For more information on using egress IP addresses in OVN-Kubernetes, see "Configuring an egress IP address".

[discrete]
[id="egress-network-policies_{context}"]
=== Egress network policies

The difference in configuring an egress network policy, also known as an egress firewall, between OVN-Kubernetes and OpenShift SDN is described in the following table:

.Differences in egress network policy configuration
[cols="1a,1a",options="header"]
|===
|OVN-Kubernetes|OpenShift SDN

|
* Create an `EgressFirewall` object in a namespace

|
* Create an `EgressNetworkPolicy` object in a namespace
|===

For more information on using an egress firewall in OVN-Kubernetes, see "Configuring an egress firewall for a project".

[discrete]
[id="egress-router-pods_{context}"]
=== Egress router pods

OVN-Kubernetes supports egress router pods in redirect mode. OVN-Kubernetes does not support egress router pods in HTTP proxy mode or DNS proxy mode.

When you deploy an egress router with the Cluster Network Operator, you cannot specify a node selector to control which node is used to host the egress router pod.

[discrete]
[id="multicast_{context}"]
=== Multicast

The difference between enabling multicast traffic on OVN-Kubernetes and OpenShift SDN is described in the following table:

.Differences in multicast configuration
[cols="1a,1a",options="header"]
|===
|OVN-Kubernetes|OpenShift SDN

|
* Add an annotation on a `Namespace` object

|
* Add an annotation on a `NetNamespace` object
|===

For more information on using multicast in OVN-Kubernetes, see "Enabling multicast for a project".

[discrete]
[id="network-policies_{context}"]
=== Network policies

OVN-Kubernetes fully supports the Kubernetes `NetworkPolicy` API in the `networking.k8s.io/v1` API group. No changes are necessary in your network policies when migrating from OpenShift SDN.

[id="how-the-migration-process-works_{context}"]
== How the migration process works

The following table summarizes the migration process by segmenting between the user-initiated steps in the process and the actions that the migration performs in response.

.Migrating to OVN-Kubernetes from OpenShift SDN
[cols="1,1a",options="header"]
|===

|User-initiated steps|Migration activity

|
Set the `migration` field of the `Network.operator.openshift.io` custom resource (CR) named `cluster` to `OVNKubernetes`. Make sure the `migration` field is `null` before setting it to a value.
|
Cluster Network Operator (CNO):: Updates the status of the `Network.config.openshift.io` CR named `cluster` accordingly.
Machine Config Operator (MCO):: Rolls out an update to the systemd configuration necessary for OVN-Kubernetes; The MCO updates a single machine per pool at a time by default, causing the total time the migration takes to increase with the size of the cluster.

|Update the `networkType` field of the `Network.config.openshift.io` CR.
|
CNO:: Performs the following actions:
+
--
* Destroys the OpenShift SDN control plane pods.
* Deploys the OVN-Kubernetes control plane pods.
* Updates the Multus objects to reflect the new cluster network provider.
--

|
Reboot each node in the cluster.
|
Cluster:: As nodes reboot, the cluster assigns IP addresses to pods on the OVN-Kubernetes cluster network.

|===

If a rollback to OpenShift SDN is required, the following table describes the process.

.Performing a rollback to OpenShift SDN
[cols="1,1a",options="header"]
|===

|User-initiated steps|Migration activity

|Suspend the MCO to ensure that it does not interrupt the migration.
|The MCO stops.

|
Set the `migration` field of the `Network.operator.openshift.io` custom resource (CR) named `cluster` to `OpenShiftSDN`. Make sure the `migration` field is `null` before setting it to a value.
|
CNO:: Updates the status of the `Network.config.openshift.io` CR named `cluster` accordingly.

|Update the `networkType` field.
|
CNO:: Performs the following actions:
+
--
* Destroys the OVN-Kubernetes control plane pods.
* Deploys the OpenShift SDN control plane pods.
* Updates the Multus objects to reflect the new cluster network provider.
--

|
Reboot each node in the cluster.
|
Cluster:: As nodes reboot, the cluster assigns IP addresses to pods on the OVN-Kubernetes cluster network.

|
Enable the MCO after all nodes in the cluster reboot.
|
MCO:: Rolls out an update to the systemd configuration necessary for OpenShift SDN; The MCO updates a single machine per pool at a time by default, so the total time the migration takes increases with the size of the cluster.

|===<commit_msg>Github-42969:fixes typo in table 5<commit_after>// Module included in the following assemblies:
//
// * networking/ovn_kubernetes_network_provider/migrate-from-openshift-sdn.adoc

[id="nw-ovn-kubernetes-migration-about_{context}"]
= Migration to the OVN-Kubernetes network provider

Migrating to the OVN-Kubernetes Container Network Interface (CNI) cluster network provider is a manual process that includes some downtime during which your cluster is unreachable. Although a rollback procedure is provided, the migration is intended to be a one-way process.


A migration to the OVN-Kubernetes cluster network provider is supported on the following platforms:

* Bare metal hardware
* Amazon Web Services (AWS)
* Google Cloud Platform (GCP)
* Microsoft Azure
* {rh-openstack-first}
* {rh-virtualization-first}
* VMware vSphere

[id="considerations-migrating-ovn-kubernetes-network-provider_{context}"]
== Considerations for migrating to the OVN-Kubernetes network provider

The subnets assigned to nodes and the IP addresses assigned to individual pods are not preserved during the migration.

While the OVN-Kubernetes network provider implements many of the capabilities present in the OpenShift SDN network provider, the configuration is not the same.

* If your cluster uses any of the following OpenShift SDN capabilities, you must manually configure the same capability in OVN-Kubernetes:
+
--
* Namespace isolation
* Egress IP addresses
* Egress network policies
* Egress router pods
* Multicast
--

* If your cluster uses any part of the `172.16.58.3/16` IP address range, you cannot migrate to OVN-Kubernetes because it uses this IP address range internally.

The following sections highlight the differences in configuration between the aforementioned capabilities in OVN-Kubernetes and OpenShift SDN.

[discrete]
[id="namespace-isolation_{context}"]
=== Namespace isolation

OVN-Kubernetes supports only the network policy isolation mode.

[IMPORTANT]
====
If your cluster uses OpenShift SDN configured in either the multitenant or subnet isolation modes, you cannot migrate to the OVN-Kubernetes network provider.
====

[discrete]
[id="egress-ip-addresses_{context}"]
=== Egress IP addresses

The differences in configuring an egress IP address between OVN-Kubernetes and OpenShift SDN is described in the following table:

.Differences in egress IP address configuration
[cols="1a,1a",options="header"]
|===
|OVN-Kubernetes|OpenShift SDN

|
* Create an `EgressIPs` object
* Add an annotation on a `Node` object

|
* Patch a `NetNamespace` object
* Patch a `HostSubnet` object
|===

For more information on using egress IP addresses in OVN-Kubernetes, see "Configuring an egress IP address".

[discrete]
[id="egress-network-policies_{context}"]
=== Egress network policies

The difference in configuring an egress network policy, also known as an egress firewall, between OVN-Kubernetes and OpenShift SDN is described in the following table:

.Differences in egress network policy configuration
[cols="1a,1a",options="header"]
|===
|OVN-Kubernetes|OpenShift SDN

|
* Create an `EgressFirewall` object in a namespace

|
* Create an `EgressNetworkPolicy` object in a namespace
|===

For more information on using an egress firewall in OVN-Kubernetes, see "Configuring an egress firewall for a project".

[discrete]
[id="egress-router-pods_{context}"]
=== Egress router pods

OVN-Kubernetes supports egress router pods in redirect mode. OVN-Kubernetes does not support egress router pods in HTTP proxy mode or DNS proxy mode.

When you deploy an egress router with the Cluster Network Operator, you cannot specify a node selector to control which node is used to host the egress router pod.

[discrete]
[id="multicast_{context}"]
=== Multicast

The difference between enabling multicast traffic on OVN-Kubernetes and OpenShift SDN is described in the following table:

.Differences in multicast configuration
[cols="1a,1a",options="header"]
|===
|OVN-Kubernetes|OpenShift SDN

|
* Add an annotation on a `Namespace` object

|
* Add an annotation on a `NetNamespace` object
|===

For more information on using multicast in OVN-Kubernetes, see "Enabling multicast for a project".

[discrete]
[id="network-policies_{context}"]
=== Network policies

OVN-Kubernetes fully supports the Kubernetes `NetworkPolicy` API in the `networking.k8s.io/v1` API group. No changes are necessary in your network policies when migrating from OpenShift SDN.

[id="how-the-migration-process-works_{context}"]
== How the migration process works

The following table summarizes the migration process by segmenting between the user-initiated steps in the process and the actions that the migration performs in response.

.Migrating to OVN-Kubernetes from OpenShift SDN
[cols="1,1a",options="header"]
|===

|User-initiated steps|Migration activity

|
Set the `migration` field of the `Network.operator.openshift.io` custom resource (CR) named `cluster` to `OVNKubernetes`. Make sure the `migration` field is `null` before setting it to a value.
|
Cluster Network Operator (CNO):: Updates the status of the `Network.config.openshift.io` CR named `cluster` accordingly.
Machine Config Operator (MCO):: Rolls out an update to the systemd configuration necessary for OVN-Kubernetes; The MCO updates a single machine per pool at a time by default, causing the total time the migration takes to increase with the size of the cluster.

|Update the `networkType` field of the `Network.config.openshift.io` CR.
|
CNO:: Performs the following actions:
+
--
* Destroys the OpenShift SDN control plane pods.
* Deploys the OVN-Kubernetes control plane pods.
* Updates the Multus objects to reflect the new cluster network provider.
--

|
Reboot each node in the cluster.
|
Cluster:: As nodes reboot, the cluster assigns IP addresses to pods on the OVN-Kubernetes cluster network.

|===

If a rollback to OpenShift SDN is required, the following table describes the process.

.Performing a rollback to OpenShift SDN
[cols="1,1a",options="header"]
|===

|User-initiated steps|Migration activity

|Suspend the MCO to ensure that it does not interrupt the migration.
|The MCO stops.

|
Set the `migration` field of the `Network.operator.openshift.io` custom resource (CR) named `cluster` to `OpenShiftSDN`. Make sure the `migration` field is `null` before setting it to a value.
|
CNO:: Updates the status of the `Network.config.openshift.io` CR named `cluster` accordingly.

|Update the `networkType` field.
|
CNO:: Performs the following actions:
+
--
* Destroys the OVN-Kubernetes control plane pods.
* Deploys the OpenShift SDN control plane pods.
* Updates the Multus objects to reflect the new cluster network provider.
--

|
Reboot each node in the cluster.
|
Cluster:: As nodes reboot, the cluster assigns IP addresses to pods on the Openshift-SDN network.

|
Enable the MCO after all nodes in the cluster reboot.
|
MCO:: Rolls out an update to the systemd configuration necessary for OpenShift SDN; The MCO updates a single machine per pool at a time by default, so the total time the migration takes increases with the size of the cluster.

|===
{'fraction_non_alphanumeric': 0.07604723081248244, 'fraction_numerical': 0.003514197357323587, 'mean_word_length': 5.047173820654484, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 2, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6532274', 'n_tokens_mistral': 4069, 'n_tokens_neox': 3882, 'n_words': 1795}