You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With current backup/restore uuids for the records are being
changed and that's result into geneve tunnels to be
disabled with the compute nodes and thus centralized
SNAT traffic is impacted when ovn_controller are
started post adoption on the networker nodes. The
traffic remains impacted until ovn_controllers are started
also on the compute nodes.
So to fix this switch to use full db files for restoration
after converting the DBs to standalone. With this also
cleaned the unused resources.
Resolves: #OSPRH-29914
Signed-off-by: Yatin Karel <ykarel@redhat.com>
Update the IP address value for `SOURCE_OVSDB_IP` to the internalApi IP address that is associated with the remaining RHOSP 17 controller VM. The IP address can be retrieved by using the following command:
33
-
----
34
-
$ $CONTROLLER_SSH ip a s enp4s0
35
-
** Select the non /32 IP address
36
-
----
37
30
[NOTE]
38
31
If you use a disconnected environment director Operator deployment, use
For more information, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html-single/deploying_an_overcloud_in_a_red_hat_openshift_container_platform_cluster_with_director_operator/index#proc_configuring-an-airgapped-environment_air-gapped-environment[Configuring an airgapped environment] in _Deploying an overcloud in a Red Hat OpenShift Container Platform cluster with director Operator_.
41
34
endif::[]
42
-
ifeval::["{build_variant}" != "ospdo"]
43
-
To get the value to set `SOURCE_OVSDB_IP`, query the puppet-generated configurations in a Controller node:
* Ensure you have SSH access to the original {rhos_prev_long} Controller nodes. This procedure extracts database files directly from the controller filesystem.
$ oc wait pod --for condition=Ready --selector=service=ovsdbserver-nb --timeout=300s
226
+
$ oc wait pod --for condition=Ready --selector=service=ovsdbserver-sb --timeout=300s
259
227
----
260
228
261
-
. Check that the data was successfully migrated by running the following commands against the new database servers, for example:
229
+
. Verify that the data was successfully migrated
262
230
+
263
231
----
264
232
$ oc exec -it ovsdbserver-nb-0 -- ovn-nbctl show
233
+
$ oc exec -it ovsdbserver-sb-0 -- ovn-sbctl show
265
234
$ oc exec -it ovsdbserver-sb-0 -- ovn-sbctl list Chassis
266
235
----
236
+
+
267
237
268
238
. Start the control plane `ovn-northd` service to keep both OVN databases in sync:
269
239
+
@@ -297,15 +267,12 @@ spec:
297
267
[NOTE]
298
268
Running OVN gateways on {OpenShiftShort} nodes might be prone to data plane downtime during Open vSwitch upgrades. Consider running OVN gateways on dedicated `Networker` data plane nodes for production deployments instead.
299
269
300
-
. Delete the `ovn-data` helper pod and the temporary `PersistentVolumeClaim` that is used to store OVN database backup files:
301
-
+
302
-
----
303
-
$ oc delete --ignore-not-found=true pod ovn-copy-data
304
-
$ oc delete --ignore-not-found=true pvc ovn-data
305
-
----
270
+
. The migration is now complete.
271
+
272
+
Consider creating a backup of the current state for rollback purposes:
306
273
+
307
274
[NOTE]
308
-
Consider taking a snapshot of the `ovn-data` helper pod and the temporary `PersistentVolumeClaim` before deleting them. For more information, see link:{defaultOCPURL}/storage/index#lvms-about-volume-snapsot_logical-volume-manager-storage[About volume snapshots] in _OpenShift Container Platform storage overview_.
275
+
The OVN databases now contain the migrated data with preserved UUIDs. Consider taking a snapshot of the database PVCs for backup purposes. For more information, see link:{defaultOCPURL}/storage/index#lvms-about-volume-snapsot_logical-volume-manager-storage[About volume snapshots] in _OpenShift Container Platform storage overview_.
0 commit comments