Skip to content

[enterprise-4.7] MTC 1.4 UI updates (1.4.0) #28996

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
apinnick merged 1 commit into from
Feb 1, 2021
Merged

[enterprise-4.7] MTC 1.4 UI updates (1.4.0) #28996

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
86 changes: 33 additions & 53 deletions modules/migration-creating-migration-plan-cam.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,70 +17,50 @@ You can create a migration plan in the for the {mtc-full} ({mtc-short}) web con
.Procedure

. In the {mtc-short} web console, click *Migration plans*.
. Click *Add migration plan*.
. Enter the *Plan name* and click *Next*.
+
The *Plan name* can contain up to 253 lower-case alphanumeric characters (`a-z, 0-9`). It must not contain spaces or underscores (`_`).
. Select a *Source cluster*.
. Select a *Target cluster*.
. Select a *Replication repository*.
. Select the projects to be migrated and click *Next*.
. Select *Copy* or *Move* for the persistent volume (PV):

. Select a *Source cluster*, a *Target cluster*, and a *Repository*, and click *Next*.
. In the *Namespaces* screen, select the projects to be migrated and click *Next*.
. In the *Persistent volumes* screen, select *Copy* or *Move* for the PVs:

* *Copy* copies the data from the PV of a source cluster to the replication repository and then restores it on a newly created PV, with similar characteristics, in the target cluster.
. Click *Add migration plan* to launch the Migration Plan wizard.
. In the *General* screen, enter the *Plan name*.
. Select a source cluster, a target cluster, and a replication repository and then click *Next*.
. In the *Namespaces* screen, select the projects to be migrated and then click *Next*.
. In the *Persistent volumes* screen, click a *Migration type* for each PV:
* The *Copy* option copies the data from the PV of a source cluster to the replication repository and then restores it on a newly created PV, with similar characteristics, in the target cluster.
+
If you specified a route to an image registry when you added the source cluster to the web console, you can migrate images directly from the source cluster to the target cluster.

* *Move* unmounts a remote volume, for example, NFS, from the source cluster, creates a PV resource on the target cluster pointing to the remote volume, and then mounts the remote volume on the target cluster. Applications running on the target cluster use the same remote volume that the source cluster was using. The remote volume must be accessible to the source and target clusters.

* The *Move* option unmounts a remote volume, for example, NFS, from the source cluster, creates a PV resource on the target cluster pointing to the remote volume, and then mounts the remote volume on the target cluster. Applications running on the target cluster use the same remote volume that the source cluster was using. The remote volume must be accessible to the source and target clusters.
. Click *Next*.

. In the *Copy options* screen, select a *Copy method* for the PVs:

* *Snapshot copy* backs up and restores the disk using the cloud provider's snapshot functionality. It is significantly faster than *Filesystem copy*.
. In the *Copy options* screen, click a *Copy method* for each PV:
* The *Snapshot copy* option backs up and restores the disk using the cloud provider's snapshot functionality. Copying snapshots is faster than copying the file system.
+
[NOTE]
====
The storage and clusters must be in the same region and the storage classes must be compatible.
====

* *Filesystem copy* backs up the files on the source cluster and restores them on the target cluster.

. You can select *Verify copy* to verify data migrated with *Filesystem copy*. Data is verified by generating a checksum for each source file and checking the checksum after restoration. Data verification significantly reduces performance.

. Select a *Target storage class*.
* The *Filesystem copy* option backs up the files on the source cluster and restores them on the target cluster.
. Select *Verify copy* if you want to verify data migrated with *Filesystem copy*. Data is verified by generating a checksum for each source file and checking the checksum after restoration. This option significantly reduces performance.
. Select a *Target storage class* for each PV.
+
If you selected *Filesystem copy*, you can change the storage class during migration, for example, from Red Hat Gluster Storage or NFS storage to Red Hat Ceph Storage.

You can change the storage class of data migrated with *Filesystem copy*.
. Click *Next*.

. In the *Migration options* screen, the *Use direct image migration* and *Use direct PV migration for filesystem copies* options are selected if you specified an image registry route for the source cluster.
. In the *Migration options* screen, the *Direct image migration* option is selected if you specified an exposed image registry route for the source cluster. The *Direct PV migration* option is selected if you are migrating data with *Filesystem copy*.
+
Direct migration is much faster than migrating files and images with a replication repository.

. If you want to add a migration hook, click *Add Hook* and perform the following steps for each migration:

.. Specify the name of the hook.
.. Select an *Ansible playbook* or a *Custom container image* for a hook written in another language.
.. Click *Browse* to upload the playbook.
.. Optional: If you are not using the default Ansible runtime image, specify a custom Ansible image.
.. Specify the cluster on which you want the hook to run, the service account name, and the namespace.
.. Select the migration step at which you want the hook to run:

* PreBackup: Before backup tasks are started on the source cluster
* PostBackup: After backup tasks are complete on the source cluster
* PreRestore: Before restore tasks are started on the target cluster
* PostRestore: After restore tasks are complete on the target cluster

. Click *Add*.
The direct migration options copy images and files directly from the source cluster to the target cluster. This option is much faster than copying images and files from the source cluster to the replication repository and then from the replication repository to the target cluster.
. Click *Next*.
. In the *Hooks* screen, click *Add Hook* to add a hook to the migration plan.
. Enter the hook name.
. If your hook is an Ansible playbook, click *Browse* to upload the playbook and update the *Ansible runtime image* field if you are using a custom Ansible image.
. If your hook is not an Ansible playbook, click *Custom container image* and specify the image name and path.
. Click *Source cluster* or *Target cluster* on which the hook should run.
. Enter the *Service account name* and the *Service account namespace* of the cluster.
. Select the migration step when the hook should run:

* *PreBackup*: Before backup tasks are started on the source cluster
* *PostBackup*: After backup tasks are complete on the source cluster
* *PreRestore*: Before restore tasks are started on the target cluster
* *PostRestore*: After restore tasks are complete on the target cluster

. Click *Add Hook* and then click *Close*.
+
You can add up to four hooks to a migration plan, assigning each hook to a different migration step.
You can add up to four hooks to a single migration plan. Each hook runs during a different migration step.

. Click *Finish*.
. Click *Close*.
. Click *Finish* and then click *Close*.
+
The migration plan appears in the *Migration plans* list.
The migration plan is displayed in the *Migration plans* list.