1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Files
openshift-docs/modules/migration-rolling-back-migration-manually.adoc
2023-10-30 10:13:25 -04:00

60 lines
1.7 KiB
Plaintext

// Module included in the following assemblies:
//
// * migrating_from_ocp_3_to_4/troubleshooting-3-4.adoc
// * migration_toolkit_for_containers/troubleshooting-mtc
:_mod-docs-content-type: PROCEDURE
[id="migration-rolling-back-migration-manually_{context}"]
= Rolling back a migration manually
You can roll back a failed migration manually by deleting the `stage` pods and unquiescing the application.
If you run the same migration plan successfully, the resources from the failed migration are deleted automatically.
[NOTE]
====
The following resources remain in the migrated namespaces after a failed direct volume migration (DVM):
* Config maps (source and destination clusters)
* `Secret` objects (source and destination clusters)
* `Rsync` CRs (source cluster)
These resources do not affect rollback. You can delete them manually.
====
.Procedure
. Delete the `stage` pods on all clusters:
+
[source,terminal]
----
$ oc delete $(oc get pods -l migration.openshift.io/is-stage-pod -n <namespace>) <1>
----
<1> Namespaces specified in the `MigPlan` CR.
. Unquiesce the application on the source cluster by scaling the replicas to their premigration number:
+
[source,terminal]
----
$ oc scale deployment <deployment> --replicas=<premigration_replicas>
----
+
The `migration.openshift.io/preQuiesceReplicas` annotation in the `Deployment` CR displays the premigration number of replicas:
+
[source,yaml]
----
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
migration.openshift.io/preQuiesceReplicas: "1"
----
. Verify that the application pods are running on the source cluster:
+
[source,terminal]
----
$ oc get pod -n <namespace>
----