mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
MIG-1622: Add new {MTC-first} attribute
Signed-off-by: A.Arnold <anarnold@redhat.com>
This commit is contained in:
A.Arnold
@@ -60,6 +60,7 @@ endif::[]
|
||||
:velero-domain: velero.io
|
||||
:velero-version: 1.14
|
||||
:launch: image:app-launcher.png[title="Application Launcher"]
|
||||
:mtc-first: Migration Toolkit for Containers (MTC)
|
||||
:mtc-short: MTC
|
||||
:mtc-full: Migration Toolkit for Containers
|
||||
:mtc-version: 1.8
|
||||
|
||||
@@ -7,7 +7,7 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
The {mtc-full} ({mtc-short}) enables you to migrate stateful application workloads between {product-title} 4 clusters at the granularity of a namespace.
|
||||
The {mtc-first} enables you to migrate stateful application workloads between {product-title} 4 clusters at the granularity of a namespace.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
||||
@@ -5,7 +5,7 @@ include::_attributes/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
You can migrate stateful application workloads between {product-title} 4 clusters at the granularity of a namespace by using the Migration Toolkit for Containers (MTC). To learn more about MTC see xref:../migration_toolkit_for_containers/about-mtc.adoc#about-mtc[understanding MTC].
|
||||
You can migrate stateful application workloads between {product-title} 4 clusters at the granularity of a namespace by using {mtc-first}. To learn more about {mtc-short} see xref:../migration_toolkit_for_containers/about-mtc.adoc#about-mtc[understanding {mtc-short}].
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
@@ -13,7 +13,7 @@ If you are migrating from {product-title} 3, see xref:../migrating_from_ocp_3_to
|
||||
====
|
||||
|
||||
[id="mtc-overview-install-mtc"]
|
||||
== Installing MTC
|
||||
== Installing {mtc-short}
|
||||
You must install the Migration Toolkit for Containers Operator that is compatible for your {product-title} version:
|
||||
|
||||
* {product-title} 4.6 and later versions: xref:../migration_toolkit_for_containers/installing-mtc.adoc#installing-mtc[Install the Migration Toolkit for Containers Operator by using Operator Lifecycle Manager (OLM)].
|
||||
@@ -22,16 +22,16 @@ You must install the Migration Toolkit for Containers Operator that is compatibl
|
||||
Then you xref:../migration_toolkit_for_containers/installing-mtc.adoc#configuring-replication-repository_installing-mtc[configure object storage to use as a replication repository].
|
||||
|
||||
[id="mtc-overview-upgrade-mtc"]
|
||||
== Upgrading MTC
|
||||
You can xref:../migration_toolkit_for_containers/upgrading-mtc.adoc#upgrading-mtc[upgrade the MTC] by using OLM.
|
||||
== Upgrading {mtc-short}
|
||||
You can xref:../migration_toolkit_for_containers/upgrading-mtc.adoc#upgrading-mtc[upgrade the {mtc-short}] by using OLM.
|
||||
|
||||
[id="mtc-overview-mtc-checklists"]
|
||||
== Reviewing MTC checklists
|
||||
Before you migrate your application workloads with the Migration Toolkit for Containers (MTC), review the xref:../migration_toolkit_for_containers/premigration-checklists-mtc.adoc#premigration-checklists-mtc[premigration checklists].
|
||||
== Reviewing {mtc-short} checklists
|
||||
Before you migrate your application workloads with the {mtc-short}, review the xref:../migration_toolkit_for_containers/premigration-checklists-mtc.adoc#premigration-checklists-mtc[premigration checklists].
|
||||
|
||||
[id="mtc-overview-migrate-mtc-applications"]
|
||||
== Migrating applications
|
||||
You can migrate your applications by using the MTC xref:../migration_toolkit_for_containers/migrating-applications-with-mtc.adoc#migrating-applications-mtc-web-console_migrating-applications-with-mtc[web console] or xref:../migration_toolkit_for_containers/advanced-migration-options-mtc.adoc#migrating-applications-cli_advanced-migration-options-mtc[the command line].
|
||||
You can migrate your applications by using the {mtc-short} xref:../migration_toolkit_for_containers/migrating-applications-with-mtc.adoc#migrating-applications-mtc-web-console_migrating-applications-with-mtc[web console] or xref:../migration_toolkit_for_containers/advanced-migration-options-mtc.adoc#migrating-applications-cli_advanced-migration-options-mtc[the command line].
|
||||
|
||||
[id="mtc-overview-advanced-migration-options"]
|
||||
== Advanced migration options
|
||||
@@ -39,7 +39,7 @@ You can automate your migrations and modify the `MigPlan` and `MigrationControll
|
||||
|
||||
* xref:../migration_toolkit_for_containers/advanced-migration-options-mtc.adoc#migration-creating-registry-route-for-dim_advanced-migration-options-mtc[Create a registry route for direct image migration]
|
||||
* xref:../migration_toolkit_for_containers/advanced-migration-options-mtc.adoc#migration-configuring-proxies_advanced-migration-options-mtc[Configuring proxies]
|
||||
* xref:../migration_toolkit_for_containers/advanced-migration-options-mtc.adoc#migration-migrating-applications-api_advanced-migration-options-mtc[Migrating an application by using the MTC API]
|
||||
* xref:../migration_toolkit_for_containers/advanced-migration-options-mtc.adoc#migration-migrating-applications-api_advanced-migration-options-mtc[Migrating an application by using the {mtc-short} API]
|
||||
* xref:../migration_toolkit_for_containers/advanced-migration-options-mtc.adoc#migration-state-migration-cli_advanced-migration-options-mtc[Running a state migration]
|
||||
* xref:../migration_toolkit_for_containers/advanced-migration-options-mtc.adoc#migration-hooks_advanced-migration-options-mtc[Creating migration hooks]
|
||||
* xref:../migration_toolkit_for_containers/advanced-migration-options-mtc.adoc#migration-plan-options_advanced-migration-options-mtc[Editing, excluding, and mapping migrated resources]
|
||||
@@ -56,13 +56,13 @@ You can perform the following troubleshooting tasks:
|
||||
* xref:../migration_toolkit_for_containers/troubleshooting-mtc.adoc#migration-using-must-gather_troubleshooting-mtc[Using the `must-gather` tool]
|
||||
* xref:../migration_toolkit_for_containers/troubleshooting-mtc.adoc#migration-debugging-velero-resources_troubleshooting-mtc[Using the Velero CLI to debug Backup and Restore CRs]
|
||||
* xref:../migration_toolkit_for_containers/troubleshooting-mtc.adoc#migration-partial-failure-velero_troubleshooting-mtc[Debugging a partial migration failure]
|
||||
* xref:../migration_toolkit_for_containers/troubleshooting-mtc.adoc#migration-using-mtc-crs-for-troubleshooting_troubleshooting-mtc[Using MTC custom resources for troubleshooting]
|
||||
* xref:../migration_toolkit_for_containers/troubleshooting-mtc.adoc#migration-using-mtc-crs-for-troubleshooting_troubleshooting-mtc[Using {mtc-short} custom resources for troubleshooting]
|
||||
* xref:../migration_toolkit_for_containers/troubleshooting-mtc.adoc#common-issues-and-concerns_troubleshooting-mtc[Checking common issues and concerns]
|
||||
|
||||
[id="mtc-overview-roll-back-mtc"]
|
||||
== Rolling back a migration
|
||||
You can xref:../migration_toolkit_for_containers/troubleshooting-mtc.adoc#rolling-back-migration_troubleshooting-mtc[roll back a migration] by using the MTC web console, the CLI or manually.
|
||||
You can xref:../migration_toolkit_for_containers/troubleshooting-mtc.adoc#rolling-back-migration_troubleshooting-mtc[roll back a migration] by using the {mtc-short} web console, the CLI or manually.
|
||||
|
||||
[id="mtc-overview-uninstall-mtc"]
|
||||
== Uninstalling MTC and deleting resources
|
||||
You can xref:../migration_toolkit_for_containers/installing-mtc.adoc#migration-uninstalling-mtc-clean-up_installing-mtc[uninstall the MTC and delete its resources] to clean up the cluster.
|
||||
== Uninstalling {mtc-short} and deleting resources
|
||||
You can xref:../migration_toolkit_for_containers/installing-mtc.adoc#migration-uninstalling-mtc-clean-up_installing-mtc[uninstall the {mtc-short} and delete its resources] to clean up the cluster.
|
||||
|
||||
@@ -7,7 +7,7 @@ include::_attributes/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
You can install the {mtc-full} ({mtc-short}) on {product-title} 4 in a restricted network environment by performing the following procedures:
|
||||
You can install the {mtc-first} on {product-title} 4 in a restricted network environment by performing the following procedures:
|
||||
|
||||
. Create a xref:../disconnected/using-olm.adoc#olm-mirror-catalog_olm-restricted-networks[mirrored Operator catalog].
|
||||
+
|
||||
@@ -47,7 +47,7 @@ This section applies only when you are working with the OpenShift API, not the w
|
||||
|
||||
OpenShift environments have the `PodSecurityAdmission` controller enabled by default. This controller requires cluster administrators to enforce Pod Security Standards by means of namespace labels. All workloads in the cluster are expected to run one of the following Pod Security Standard levels: `Privileged`, `Baseline` or `Restricted`. Every cluster has its own default policy set.
|
||||
|
||||
To guarantee successful data transfer in all environments, {mtc-full} ({mtc-short}) 1.7.5 introduced changes in Rsync pods, including running Rsync pods as non-root user by default. This ensures that data transfer is possible even for workloads that do not necessarily require higher privileges. This change was made because it is best to run workloads with the lowest level of privileges possible.
|
||||
To guarantee successful data transfer in all environments, {mtc-short} 1.7.5 introduced changes in Rsync pods, including running Rsync pods as non-root user by default. This ensures that data transfer is possible even for workloads that do not necessarily require higher privileges. This change was made because it is best to run workloads with the lowest level of privileges possible.
|
||||
|
||||
[discrete]
|
||||
[id="migration-rsync-override-data-transfer_{context}"]
|
||||
|
||||
@@ -7,7 +7,7 @@ include::_attributes/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
You can install the {mtc-full} ({mtc-short}) on {product-title} 4.
|
||||
You can install the {mtc-first} on {product-title} 4.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
@@ -41,7 +41,7 @@ This section applies only when you are working with the OpenShift API, not the w
|
||||
|
||||
OpenShift environments have the `PodSecurityAdmission` controller enabled by default. This controller requires cluster administrators to enforce Pod Security Standards by means of namespace labels. All workloads in the cluster are expected to run one of the following Pod Security Standard levels: `Privileged`, `Baseline` or `Restricted`. Every cluster has its own default policy set.
|
||||
|
||||
To guarantee successful data transfer in all environments, {mtc-full} ({mtc-short}) 1.7.5 introduced changes in Rsync pods, including running Rsync pods as non-root user by default. This ensures that data transfer is possible even for workloads that do not necessarily require higher privileges. This change was made because it is best to run workloads with the lowest level of privileges possible.
|
||||
To guarantee successful data transfer in all environments, {mtc-short} 1.7.5 introduced changes in Rsync pods, including running Rsync pods as non-root user by default. This ensures that data transfer is possible even for workloads that do not necessarily require higher privileges. This change was made because it is best to run workloads with the lowest level of privileges possible.
|
||||
|
||||
==== Manually overriding default non-root operation for data trannsfer
|
||||
|
||||
@@ -62,7 +62,7 @@ include::modules/migration-rsync-mig-migration-root-non-root.adoc[leveloffset=+2
|
||||
[id="configuring-replication-repository_{context}"]
|
||||
== Configuring a replication repository
|
||||
|
||||
You must configure an object storage to use as a replication repository. The {mtc-full} ({mtc-short}) copies data from the source cluster to the replication repository, and then from the replication repository to the target cluster.
|
||||
You must configure an object storage to use as a replication repository. The {mtc-first} copies data from the source cluster to the replication repository, and then from the replication repository to the target cluster.
|
||||
|
||||
{mtc-short} supports the xref:../migration_toolkit_for_containers/about-mtc.adoc#migration-understanding-data-copy-methods_about-mtc[file system and snapshot data copy methods] for migrating data from the source cluster to the target cluster. Select a method that is suited for your environment and is supported by your storage provider.
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
You can migrate your applications by using the {mtc-full} ({mtc-short}) web console or the xref:../migration_toolkit_for_containers/advanced-migration-options-mtc.adoc#migrating-applications-cli_advanced-migration-options-mtc[command line].
|
||||
You can migrate your applications by using the {mtc-first} web console or the xref:../migration_toolkit_for_containers/advanced-migration-options-mtc.adoc#migrating-applications-cli_advanced-migration-options-mtc[command line].
|
||||
|
||||
Most cluster-scoped resources are not yet handled by {mtc-short}. If your applications require cluster-scoped resources, you might have to create them manually on the target cluster.
|
||||
|
||||
@@ -20,7 +20,7 @@ You can use state migration to migrate an application's state:
|
||||
* State migration copies selected persistent volume claims (PVCs).
|
||||
* You can use state migration to migrate a namespace within the same cluster.
|
||||
|
||||
During migration, the {mtc-full} ({mtc-short}) preserves the following namespace annotations:
|
||||
During migration, the {mtc-short} preserves the following namespace annotations:
|
||||
|
||||
* `openshift.io/sa.scc.mcs`
|
||||
* `openshift.io/sa.scc.supplemental-groups`
|
||||
|
||||
@@ -8,7 +8,7 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
Direct Migration is available with {mtc-full} ({mtc-short}) 1.4.0 or later.
|
||||
Direct Migration is available with {mtc-first} 1.4.0 or later.
|
||||
|
||||
There are two parts of the Direct Migration:
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
Before you migrate your application workloads with the {mtc-full} ({mtc-short}), review the following checklists.
|
||||
Before you migrate your application workloads with the {mtc-first}, review the following checklists.
|
||||
|
||||
[id="cluster-health-checklist_{context}"]
|
||||
== Cluster health checklist
|
||||
|
||||
@@ -7,7 +7,7 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
The release notes for {mtc-full} ({mtc-short}) describe new features and enhancements, deprecated features, and known issues.
|
||||
The release notes for {mtc-first} describe new features and enhancements, deprecated features, and known issues.
|
||||
|
||||
The {mtc-short} enables you to migrate application workloads between {product-title} clusters at the granularity of a namespace.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
The release notes for {mtc-full} ({mtc-short}) describe new features and enhancements, deprecated features, and known issues.
|
||||
The release notes for {mtc-first} describe new features and enhancements, deprecated features, and known issues.
|
||||
|
||||
The {mtc-short} enables you to migrate application workloads between {product-title} clusters at the granularity of a namespace.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
The release notes for {mtc-full} ({mtc-short}) describe new features and enhancements, deprecated features, and known issues.
|
||||
The release notes for {mtc-first} describe new features and enhancements, deprecated features, and known issues.
|
||||
|
||||
The {mtc-short} enables you to migrate application workloads between {product-title} clusters at the granularity of a namespace.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
The release notes for {mtc-full} ({mtc-short}) describe new features and enhancements, deprecated features, and known issues.
|
||||
The release notes for {mtc-first} describe new features and enhancements, deprecated features, and known issues.
|
||||
|
||||
The {mtc-short} enables you to migrate application workloads between {product-title} clusters at the granularity of a namespace.
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
This section describes resources for troubleshooting the {mtc-full} ({mtc-short}).
|
||||
This section describes resources for troubleshooting the {mtc-first}.
|
||||
|
||||
For known issues, see the xref:../migration_toolkit_for_containers/release_notes/mtc-release-notes.adoc#mtc-release-notes[{mtc-short} release notes].
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ include::_attributes/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
You can upgrade the {mtc-full} ({mtc-short}) on {product-title} {product-version} by using Operator Lifecycle Manager.
|
||||
You can upgrade the {mtc-first} on {product-title} {product-version} by using Operator Lifecycle Manager.
|
||||
|
||||
You can upgrade {mtc-short} on {product-title} 4.5, and earlier versions, by reinstalling the legacy {mtc-full} Operator.
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
[id="configuring-retries-for-rsync_{context}"]
|
||||
= Rsync retry configuration
|
||||
|
||||
With MTC 1.4.3 and later, a new ability of retrying a failed Rsync operation is introduced.
|
||||
With {mtc-first} 1.4.3 and later, a new ability of retrying a failed Rsync operation is introduced.
|
||||
|
||||
By default, the migration controller retries Rsync until all of the data is successfully transferred from the source to the target volume or a specified number of retries is met. The default retry limit is set to `+20+`.
|
||||
|
||||
|
||||
@@ -11,12 +11,12 @@
|
||||
|
||||
For {product-title} 4.1 and earlier versions, you must configure proxies in the `MigrationController` custom resource (CR) manifest after you install the {mtc-full} Operator because these versions do not support a cluster-wide `proxy` object.
|
||||
|
||||
For {product-title} 4.2 to {product-version}, the {mtc-full} ({mtc-short}) inherits the cluster-wide proxy settings. You can change the proxy parameters if you want to override the cluster-wide proxy settings.
|
||||
For {product-title} 4.2 to {product-version}, the {mtc-short} inherits the cluster-wide proxy settings. You can change the proxy parameters if you want to override the cluster-wide proxy settings.
|
||||
|
||||
[id="direct-volume-migration_{context}"]
|
||||
== Direct volume migration
|
||||
|
||||
Direct Volume Migration (DVM) was introduced in MTC 1.4.2. DVM supports only one proxy. The source cluster cannot access the route of the target cluster if the target cluster is also behind a proxy.
|
||||
Direct Volume Migration (DVM) was introduced in {mtc-short} 1.4.2. DVM supports only one proxy. The source cluster cannot access the route of the target cluster if the target cluster is also behind a proxy.
|
||||
|
||||
If you want to perform a DVM from a source cluster behind a proxy, you must configure a TCP proxy that works at the transport layer and forwards the SSL connections transparently without decrypting and re-encrypting them with their own SSL certificates. A Stunnel proxy is an example of such a proxy.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="migration-about-mtc-custom-resources_{context}"]
|
||||
= About {mtc-short} custom resources
|
||||
|
||||
The {mtc-full} ({mtc-short}) creates the following custom resources (CRs):
|
||||
The {mtc-first} creates the following custom resources (CRs):
|
||||
|
||||
image::migration-architecture.png[migration architecture diagram]
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="migration-adding-cluster-to-cam_{context}"]
|
||||
= Adding a cluster to the {mtc-short} web console
|
||||
|
||||
You can add a cluster to the {mtc-full} ({mtc-short}) web console.
|
||||
You can add a cluster to the {mtc-first} web console.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="migration-adding-replication-repository-to-cam_{context}"]
|
||||
= Adding a replication repository to the {mtc-short} web console
|
||||
|
||||
You can add an object storage as a replication repository to the {mtc-full} ({mtc-short}) web console.
|
||||
You can add an object storage as a replication repository to the {mtc-first} web console.
|
||||
|
||||
{mtc-short} supports the following storage providers:
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="migration-changing-migration-plan-limits_{context}"]
|
||||
= Increasing limits for large migrations
|
||||
|
||||
You can increase the limits on migration objects and container resources for large migrations with the {mtc-full} ({mtc-short}).
|
||||
You can increase the limits on migration objects and container resources for large migrations with the {mtc-first}.
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="migration-compatibility-guidelines-3-to-4_{context}"]
|
||||
= Compatibility guidelines
|
||||
|
||||
You must install the {mtc-full} ({mtc-short}) Operator that is compatible with your {product-title} version.
|
||||
You must install the {mtc-first} Operator that is compatible with your {product-title} version.
|
||||
|
||||
.Definitions
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="migration-compatibility-guidelines_{context}"]
|
||||
= Compatibility guidelines
|
||||
|
||||
You must install the {mtc-full} ({mtc-short}) Operator that is compatible with your {product-title} version.
|
||||
You must install the {mtc-first} Operator that is compatible with your {product-title} version.
|
||||
|
||||
.Definitions
|
||||
|
||||
@@ -18,7 +18,7 @@ modern operator:: The {mtc-short} Operator designed for modern platforms.
|
||||
control cluster:: The cluster that runs the {mtc-short} controller and GUI.
|
||||
remote cluster:: A source or destination cluster for a migration that runs Velero. The Control Cluster communicates with Remote clusters via the Velero API to drive migrations.
|
||||
|
||||
You must use the compatible {mtc-short} version for migrating your {product-title} clusters. For the migration to succeed both your source cluster and the destination cluster must use the same version of MTC.
|
||||
You must use the compatible {mtc-short} version for migrating your {product-title} clusters. For the migration to succeed both your source cluster and the destination cluster must use the same version of {mtc-short}.
|
||||
|
||||
MTC 1.7 supports migrations from {product-title} 3.11 to 4.9.
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@
|
||||
= Configuring Amazon Web Services
|
||||
|
||||
ifdef::installing-3-4,installing-mtc[]
|
||||
You configure Amazon Web Services (AWS) S3 object storage as a replication repository for the {mtc-full} ({mtc-short}).
|
||||
You configure Amazon Web Services (AWS) S3 object storage as a replication repository for the {mtc-first} .
|
||||
endif::[]
|
||||
ifdef::installing-oadp-aws[]
|
||||
You configure Amazon Web Services (AWS) for the OpenShift API for Data Protection (OADP).
|
||||
|
||||
@@ -9,7 +9,7 @@
|
||||
= Configuring {azure-full}
|
||||
|
||||
ifdef::installing-3-4,installing-mtc[]
|
||||
You configure a {azure-full} Blob storage container as a replication repository for the {mtc-full} ({mtc-short}).
|
||||
You configure a {azure-full} Blob storage container as a replication repository for the {mtc-first}.
|
||||
endif::[]
|
||||
ifdef::installing-oadp-azure[]
|
||||
You configure {azure-full} for {oadp-first}.
|
||||
|
||||
@@ -9,7 +9,7 @@
|
||||
= Configuring Google Cloud Platform
|
||||
|
||||
ifdef::installing-3-4,installing-mtc[]
|
||||
You configure a Google Cloud Platform (GCP) storage bucket as a replication repository for the {mtc-full} ({mtc-short}).
|
||||
You configure a Google Cloud Platform (GCP) storage bucket as a replication repository for the {mtc-first}.
|
||||
endif::[]
|
||||
ifdef::installing-oadp-gcp[]
|
||||
You configure Google Cloud Platform (GCP) for the OpenShift API for Data Protection (OADP).
|
||||
|
||||
@@ -11,7 +11,7 @@
|
||||
= Retrieving Multicloud Object Gateway credentials
|
||||
|
||||
ifdef::installing-3-4,installing-mtc[]
|
||||
You must retrieve the Multicloud Object Gateway (MCG) credentials and S3 endpoint, which you need to configure MCG as a replication repository for the {mtc-full} ({mtc-short})
|
||||
You must retrieve the Multicloud Object Gateway (MCG) credentials and S3 endpoint, which you need to configure MCG as a replication repository for the {mtc-first}.
|
||||
|
||||
You must retrieve the Multicloud Object Gateway (MCG) credentials, which you need to create a `Secret` custom resource (CR) for {mtc-short}.
|
||||
endif::[]
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
[id="migration-converting-storage-classes_{context}"]
|
||||
= Converting storage classes in the {mtc-short} web console
|
||||
|
||||
You can convert the storage class of a persistent volume (PV) by migrating it within the same cluster. To do so, you must create and run a migration plan in the {mtc-full} ({mtc-short}) web console.
|
||||
You can convert the storage class of a persistent volume (PV) by migrating it within the same cluster. To do so, you must create and run a migration plan in the {mtc-first} web console.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
[id="creating-ca-bundle_{context}"]
|
||||
= Creating a CA certificate bundle file for self-signed certificates
|
||||
|
||||
If you use a self-signed certificate to secure a cluster or a replication repository for the {mtc-full} ({mtc-short}), certificate verification might fail with the following error message: `Certificate signed by unknown authority`.
|
||||
If you use a self-signed certificate to secure a cluster or a replication repository for the {mtc-first}, certificate verification might fail with the following error message: `Certificate signed by unknown authority`.
|
||||
|
||||
You can create a custom CA certificate bundle file and upload it in the {mtc-short} web console when you add a cluster or a replication repository.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="migration-creating-migration-plan-cam_{context}"]
|
||||
= Creating a migration plan in the {mtc-short} web console
|
||||
|
||||
You can create a migration plan in the {mtc-full} ({mtc-short}) web console.
|
||||
You can create a migration plan in the {mtc-first} web console.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@
|
||||
|
||||
If direct volume migration does not complete, the target cluster might not have the same `node-selector` annotations as the source cluster.
|
||||
|
||||
{mtc-full} ({mtc-short}) migrates namespaces with all annotations to preserve security context constraints and scheduling requirements. During direct volume migration, {mtc-short} creates Rsync transfer pods on the target cluster in the namespaces that were migrated from the source cluster. If a target cluster namespace does not have the same annotations as the source cluster namespace, the Rsync transfer pods cannot be scheduled. The Rsync pods remain in a `Pending` state.
|
||||
{mtc-first} migrates namespaces with all annotations to preserve security context constraints and scheduling requirements. During direct volume migration, {mtc-short} creates Rsync transfer pods on the target cluster in the namespaces that were migrated from the source cluster. If a target cluster namespace does not have the same annotations as the source cluster namespace, the Rsync transfer pods cannot be scheduled. The Rsync pods remain in a `Pending` state.
|
||||
|
||||
You can identify and fix this issue by performing the following procedure.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="migration-error-messages_{context}"]
|
||||
= Error messages and resolutions
|
||||
|
||||
This section describes common error messages you might encounter with the {mtc-full} ({mtc-short}) and how to resolve their underlying causes.
|
||||
This section describes common error messages you might encounter with the {mtc-first} and how to resolve their underlying causes.
|
||||
|
||||
[id="ca-certificate-error-displayed-when-accessing-console-for-first-time_{context}"]
|
||||
== CA certificate error displayed when accessing the {mtc-short} console for the first time
|
||||
@@ -35,7 +35,7 @@ To determine the cause:
|
||||
[id="certificate-signed-by-unknown-authority-error_{context}"]
|
||||
== Certificate signed by unknown authority error
|
||||
|
||||
If you use a self-signed certificate to secure a cluster or a replication repository for the {mtc-full} ({mtc-short}), certificate verification might fail with the following error message: `Certificate signed by unknown authority`.
|
||||
If you use a self-signed certificate to secure a cluster or a replication repository for the {mtc-short}, certificate verification might fail with the following error message: `Certificate signed by unknown authority`.
|
||||
|
||||
You can create a custom CA certificate bundle file and upload it in the {mtc-short} web console when you add a cluster or a replication repository.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="migration-excluding-resources_{context}"]
|
||||
= Excluding resources
|
||||
|
||||
You can exclude resources, for example, image streams, persistent volumes (PVs), or subscriptions, from a {mtc-full} ({mtc-short}) migration plan to reduce the resource load for migration or to migrate images or PVs with a different tool.
|
||||
You can exclude resources, for example, image streams, persistent volumes (PVs), or subscriptions, from a {mtc-first} migration plan to reduce the resource load for migration or to migrate images or PVs with a different tool.
|
||||
|
||||
By default, the {mtc-short} excludes service catalog resources and Operator Lifecycle Manager (OLM) resources from migration. These resources are parts of the service catalog API group and the OLM API group, neither of which is supported for migration at this time.
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
This release has the following known issues:
|
||||
|
||||
* During migration, the {mtc-full} ({mtc-short}) preserves the following namespace annotations:
|
||||
* During migration, the {mtc-first} preserves the following namespace annotations:
|
||||
|
||||
** `openshift.io/sa.scc.mcs`
|
||||
** `openshift.io/sa.scc.supplemental-groups`
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="migration-kubernetes-objects_{context}"]
|
||||
= Performing a state migration of Kubernetes objects by using the {mtc-short} API
|
||||
|
||||
After you migrate all the PV data, you can use the Migration Toolkit for Containers (MTC) API to perform a one-time state migration of Kubernetes objects that constitute an application.
|
||||
After you migrate all the PV data, you can use the {mtc-first} API to perform a one-time state migration of Kubernetes objects that constitute an application.
|
||||
|
||||
You do this by configuring `MigPlan` custom resource (CR) fields to provide a list of Kubernetes resources with an additional label selector to further filter those resources, and then performing a migration by creating a `MigMigration` CR. The `MigPlan` resource is closed after the migration.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="migration-launching-cam_{context}"]
|
||||
= Launching the {mtc-short} web console
|
||||
|
||||
You can launch the {mtc-full} ({mtc-short}) web console in a browser.
|
||||
You can launch the {mtc-first} web console in a browser.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="migration-migrating-applications-api_{context}"]
|
||||
= Migrating an application by using the {mtc-short} API
|
||||
|
||||
You can migrate an application from the command line by using the {mtc-full} ({mtc-short}) API.
|
||||
You can migrate an application from the command line by using the {mtc-first} API.
|
||||
|
||||
.Procedure
|
||||
|
||||
|
||||
@@ -4,9 +4,9 @@
|
||||
// * migration_toolkit_for_containers/migrating-applications-with-mtc
|
||||
|
||||
[id="migration-mtc-cr-manifests_{context}"]
|
||||
= {mtc-short} custom resource manifests
|
||||
= {mtc-full} custom resource manifests
|
||||
|
||||
{mtc-full} ({mtc-short}) uses the following custom resource (CR) manifests for migrating applications.
|
||||
{mtc-first} uses the following custom resource (CR) manifests for migrating applications.
|
||||
|
||||
[id="directimagemigration_{context}"]
|
||||
== DirectImageMigration
|
||||
|
||||
@@ -22,7 +22,7 @@ MigPlan cannot be validated because the destination namespace starts with a non-
|
||||
The Cloud propagation phase in the migration controller is not functioning due to missing labels on Velero pods. The `EnsureCloudSecretPropagated` phase in the migration controller waits until replication repository secrets are propagated on both sides. As this label is missing on Velero pods, the phase is not functioning as expected. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2088026[*BZ#2088026*])
|
||||
|
||||
.Default CPU requests on Velero/Restic are too demanding when making scheduling fail in certain environments
|
||||
Default CPU requests on Velero/Restic are too demanding when making scheduling fail in certain environments. Default CPU requests for Velero and Restic Pods are set to 500m. These values are high. The resources can be configured in DPA using the `podConfig` field for Velero and Restic. Migration operator should set CPU requests to a lower value, such as 100m, so that Velero and Restic pods can be scheduled in resource constrained environments MTC often operates in. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2088022[*BZ#2088022*])
|
||||
Default CPU requests on Velero/Restic are too demanding when making scheduling fail in certain environments. Default CPU requests for Velero and Restic Pods are set to 500m. These values are high. The resources can be configured in DPA using the `podConfig` field for Velero and Restic. Migration operator should set CPU requests to a lower value, such as 100m, so that Velero and Restic pods can be scheduled in resource constrained environments {mtc-first} often operates in. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2088022[*BZ#2088022*])
|
||||
|
||||
.Warning is displayed on persistentVolumes page after editing storage class conversion plan
|
||||
A warning is displayed on the *persistentVolumes* page after editing the storage class conversion plan. When editing the existing migration plan, a warning is displayed on the UI `At least one PVC must be selected for Storage Class Conversion`. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2079549[*BZ#2079549*])
|
||||
|
||||
@@ -11,7 +11,7 @@
|
||||
This release has the following major resolved issues:
|
||||
|
||||
.MTC UI does not display logs correctly
|
||||
In previous releases, the MTC UI did not display logs correctly. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2062266[*BZ#2062266*])
|
||||
In previous releases, the {mtc-first} UI did not display logs correctly. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2062266[*BZ#2062266*])
|
||||
|
||||
.StorageClass conversion plan adding migstorage reference in migplan
|
||||
In previous releases, StorageClass conversion plans had a `migstorage` reference even though it was not being used. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2078459[*BZ#2078459*])
|
||||
|
||||
@@ -15,5 +15,5 @@ There are no major resolved issues in this release.
|
||||
== Known issues
|
||||
|
||||
.Rollback missing out deletion of some resources from the target cluster
|
||||
On performing the roll back of an application from the MTC UI, some resources are not being deleted from the target cluster and the roll back is showing a status as successfully completed. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2126880[*BZ#2126880*])
|
||||
On performing the roll back of an application from the {mtc-first} UI, some resources are not being deleted from the target cluster and the roll back is showing a status as successfully completed. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2126880[*BZ#2126880*])
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ In previous release, migration succeeded with warnings but Direct Volume Migrati
|
||||
|
||||
This release has the following known issues:
|
||||
|
||||
.Velero image cannot be overridden in the MTC operator
|
||||
.Velero image cannot be overridden in the {mtc-first} operator
|
||||
In previous releases, it was not possible to override the velero image using the `velero_image_fqin` parameter in the `MigrationController` Custom Resource (CR). (link:https://bugzilla.redhat.com/show_bug.cgi?id=2143389[*BZ#2143389*])
|
||||
|
||||
.When editing a MigHook in the UI, the page might fail to reload
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
|
||||
This release has the following major resolved issues:
|
||||
|
||||
.Velero image cannot be overridden in the MTC operator
|
||||
.Velero image cannot be overridden in the {mtc-first} operator
|
||||
In previous releases, it was not possible to override the velero image using the `velero_image_fqin` parameter in the `MigrationController` Custom Resource (CR). (link:https://bugzilla.redhat.com/show_bug.cgi?id=2143389[*BZ#2143389*])
|
||||
|
||||
.Adding a MigCluster from the UI fails when the domain name has more than six characters
|
||||
@@ -20,7 +20,7 @@ In previous releases, adding a MigCluster from the UI failed when the domain nam
|
||||
In previous releases, the UI failed to render the Migrations' page, returning `Cannot read properties of undefined (reading 'name')`. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2163485[*BZ#2163485*])
|
||||
|
||||
.Creating DPA resource fails on Red Hat OpenShift Container Platform 4.6 clusters
|
||||
In previous releases, when deploying MTC on an {OCP} 4.6 cluster, the DPA failed to be created according to the logs, which resulted in some pods missing. From the logs in the migration-controller in the OCP 4.6 cluster, it indicated that an unexpected `null` value was passed, which caused the error. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2173742[*BZ#2173742*])
|
||||
In previous releases, when deploying {mtc-short} on an {OCP} 4.6 cluster, the DPA failed to be created according to the logs, which resulted in some pods missing. From the logs in the migration-controller in the {OCP} 4.6 cluster, it indicated that an unexpected `null` value was passed, which caused the error. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2173742[*BZ#2173742*])
|
||||
|
||||
[id="known-issues-1-7-08_{context}"]
|
||||
== Known issues
|
||||
|
||||
@@ -21,6 +21,6 @@ This release has the following known issues:
|
||||
|
||||
On the *Migration details* page, at first, the `migration details` are displayed without any issues. However, after sometime, the details disappear, and a `504` error is returned. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2231106[*BZ#2231106*])
|
||||
|
||||
.Old restic pods are not removed when upgrading MTC 1.7.x to MTC 1.8
|
||||
.Old restic pods are not removed when upgrading {mtc-full} 1.7.x to {mtc-full} 1.8
|
||||
|
||||
On upgrading the MTC operator from 1.7.x to 1.8.x, the old restic pods are not removed. After the upgrade, both restic and node-agent pods are visible in the namespace. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2236829[*BZ#2236829*])
|
||||
On upgrading the {mtc-first} operator from 1.7.x to 1.8.x, the old restic pods are not removed. After the upgrade, both restic and node-agent pods are visible in the namespace. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2236829[*BZ#2236829*])
|
||||
|
||||
@@ -12,7 +12,7 @@ This release has the following resolved issues:
|
||||
|
||||
.CVE-2023-39325 CVE-2023-44487: various flaws
|
||||
|
||||
A flaw was found in the handling of multiplexed streams in the HTTP/2 protocol, which is utilized by {mtc-full} ({mtc-short}). A client could repeatedly make a request for a new multiplex stream then immediately send an `RST_STREAM` frame to cancel those requests. This activity created additional workloads for the server in terms of setting up and dismantling streams, but avoided any server-side limitations on the maximum number of active streams per connection. As a result, a denial of service occurred due to server resource consumption.
|
||||
A flaw was found in the handling of multiplexed streams in the HTTP/2 protocol, which is utilized by {mtc-first}. A client could repeatedly make a request for a new multiplex stream then immediately send an `RST_STREAM` frame to cancel those requests. This activity created additional workloads for the server in terms of setting up and dismantling streams, but avoided any server-side limitations on the maximum number of active streams per connection. As a result, a denial of service occurred due to server resource consumption.
|
||||
|
||||
* link:https://bugzilla.redhat.com/show_bug.cgi?id=2243564[(BZ#2243564)]
|
||||
* link:https://bugzilla.redhat.com/show_bug.cgi?id=2244013[(BZ#2244013)]
|
||||
|
||||
@@ -6,4 +6,4 @@
|
||||
[id="migration-mtc-release-notes-1-7-17_{context}"]
|
||||
= {mtc-full} 1.7.17 release notes
|
||||
|
||||
{mtc-full} ({mtc-short}) 1.7.17 is a Container Grade Only (CGO) release, released to refresh the health grades of the containers, with no changes to any code in the product itself compared to that of {mtc-short} 1.7.16.
|
||||
{mtc-first} 1.7.17 is a Container Grade Only (CGO) release, released to refresh the health grades of the containers, with no changes to any code in the product itself compared to that of {mtc-short} 1.7.16.
|
||||
|
||||
@@ -10,11 +10,11 @@
|
||||
|
||||
This release has the following new features and enhancements:
|
||||
|
||||
* The {mtc-full} ({mtc-short}) Operator now depends upon the OpenShift API for Data Protection (OADP) Operator. When you install the {mtc-short} Operator, the Operator Lifecycle Manager (OLM) automatically installs the OADP Operator in the same namespace.
|
||||
* The {mtc-first} Operator now depends upon the OpenShift API for Data Protection (OADP) Operator. When you install the {mtc-short} Operator, the Operator Lifecycle Manager (OLM) automatically installs the OADP Operator in the same namespace.
|
||||
|
||||
* You can migrate from a source cluster that is behind a firewall to a cloud-based destination cluster by establishing a network tunnel between the two clusters by using the `crane tunnel-api` command.
|
||||
|
||||
* Converting storage classes in the MTC web console: You can convert the storage class of a persistent volume (PV) by migrating it within the same cluster.
|
||||
* Converting storage classes in the {mtc-short} web console: You can convert the storage class of a persistent volume (PV) by migrating it within the same cluster.
|
||||
|
||||
[id="known-issues-1-7_{context}"]
|
||||
== Known issues
|
||||
@@ -24,4 +24,4 @@ This release has the following known issues:
|
||||
* `MigPlan` custom resource does not display a warning when an AWS gp2 PVC has no available space. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1963927[*BZ#1963927*])
|
||||
* Direct and indirect data transfers do not work if the destination storage is a PV that is dynamically provisioned by the AWS Elastic File System (EFS). This is due to limitations of the AWS EFS Container Storage Interface (CSI) driver. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2085097[*BZ#2085097*])
|
||||
* Block storage for IBM Cloud must be in the same availability zone. See the link:https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-vpc-faq[IBM FAQ for block storage for virtual private cloud].
|
||||
* MTC 1.7.6 cannot migrate cron jobs from source clusters that support `v1beta1` cron jobs to clusters of {product-title} 4.12 and later, which do not support `v1beta1` cron jobs. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2149119[*BZ#2149119*])
|
||||
* {mtc-short} 1.7.6 cannot migrate cron jobs from source clusters that support `v1beta1` cron jobs to clusters of {product-title} 4.12 and later, which do not support `v1beta1` cron jobs. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2149119[*BZ#2149119*])
|
||||
|
||||
@@ -8,11 +8,11 @@
|
||||
[id="resolved-issues-1-8-1_{context}"]
|
||||
== Resolved issues
|
||||
|
||||
{mtc-full} ({mtc-short}) 1.8.1 has the following major resolved issues:
|
||||
{mtc-first} 1.8.1 has the following major resolved issues:
|
||||
|
||||
.CVE-2023-39325: golang: net/http, x/net/http2: rapid stream resets can cause excessive work
|
||||
|
||||
A flaw was found in handling multiplexed streams in the HTTP/2 protocol, which is used by {mtc-full} ({mtc-short}). A client could repeatedly make a request for a new multiplex stream and immediately send an `RST_STREAM` frame to cancel it. This creates additional workload for the server in terms of setting up and dismantling streams, while avoiding any server-side limitations on the maximum number of active streams per connection, resulting in a denial of service due to server resource consumption. link:https://bugzilla.redhat.com/show_bug.cgi?id=2245079[(BZ#2245079)]
|
||||
A flaw was found in handling multiplexed streams in the HTTP/2 protocol, which is used by {mtc-short}. A client could repeatedly make a request for a new multiplex stream and immediately send an `RST_STREAM` frame to cancel it. This creates additional workload for the server in terms of setting up and dismantling streams, while avoiding any server-side limitations on the maximum number of active streams per connection, resulting in a denial of service due to server resource consumption. link:https://bugzilla.redhat.com/show_bug.cgi?id=2245079[(BZ#2245079)]
|
||||
|
||||
It is advised to update to {mtc-short} 1.8.1 or later, which resolve this issue.
|
||||
|
||||
@@ -23,7 +23,7 @@ For more details, see link:https://access.redhat.com/security/cve/cve-2023-39325
|
||||
[id="known-issues-1-8-1_{context}"]
|
||||
== Known issues
|
||||
|
||||
{mtc-full} ({mtc-short}) 1.8.1 has the following known issues:
|
||||
{mtc-first} 1.8.1 has the following known issues:
|
||||
|
||||
.Ansible Operator is broken when {VirtProductName} is installed
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ This release has the following major resolved issues:
|
||||
|
||||
.Backup phase fails after setting custom CA replication repository
|
||||
|
||||
In previous releases of {mtc-full} ({mtc-short}), after editing the replication repository, adding a custom CA certificate, successfully connecting the repository, and triggering a migration, a failure occurred during the backup phase.
|
||||
In previous releases of {mtc-first}, after editing the replication repository, adding a custom CA certificate, successfully connecting the repository, and triggering a migration, a failure occurred during the backup phase.
|
||||
|
||||
.CVE-2023-26136: tough-cookie package before 4.1.3 are vulnerable to Prototype Pollution
|
||||
|
||||
@@ -30,7 +30,7 @@ For more details, see link:https://access.redhat.com/security/cve/cve-2022-25883
|
||||
[id="known-issues-1-8-2_{context}"]
|
||||
== Known issues
|
||||
|
||||
{mtc-full} ({mtc-short}) 1.8.2 has the following known issues:
|
||||
{mtc-short} 1.8.2 has the following known issues:
|
||||
|
||||
.Ansible Operator is broken when {VirtProductName} is installed
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
[id=technical-changes-1-8-3_{context}]
|
||||
== Technical changes
|
||||
|
||||
{mtc-full} ({mtc-short}) 1.8.3 has the following technical changes:
|
||||
{mtc-first} 1.8.3 has the following technical changes:
|
||||
|
||||
.{oadp-short} 1.3 is now supported
|
||||
|
||||
@@ -17,7 +17,7 @@
|
||||
[id="resolved-issues-1-8-3_{context}"]
|
||||
== Resolved issues
|
||||
|
||||
{mtc-full} ({mtc-short}) 1.8.3 has the following major resolved issues:
|
||||
{mtc-short} 1.8.3 has the following major resolved issues:
|
||||
|
||||
.CVE-2024-24786: Flaw in Golang `protobuf` module causes `unmarshal` function to enter infinite loop
|
||||
|
||||
@@ -52,7 +52,7 @@ For a complete list of all resolved issues, see the list of link:https://issues.
|
||||
[id="known-issues-1-8-3_{context}"]
|
||||
== Known issues
|
||||
|
||||
{mtc-full} ({mtc-short}) 1.8.3 has the following known issues:
|
||||
{mtc-first} 1.8.3 has the following known issues:
|
||||
|
||||
.Ansible Operator is broken when {VirtProductName} is installed
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
[id="technical-changes-1-8-4_{context}"]
|
||||
== Technical changes
|
||||
|
||||
{mtc-full} ({mtc-short}) 1.8.4 has the following technical changes:
|
||||
{mtc-first} 1.8.4 has the following technical changes:
|
||||
|
||||
* {mtc-short} 1.8.4 extends its dependency resolution to include support for using {oadp-first} 1.4.
|
||||
|
||||
@@ -19,7 +19,7 @@
|
||||
[id="resolved-issues-1-8-4_{context}"]
|
||||
== Resolved issues
|
||||
|
||||
{mtc-full} ({mtc-short}) 1.8.4 has the following major resolved issues:
|
||||
{mtc-short} 1.8.4 has the following major resolved issues:
|
||||
|
||||
.Ansible Operator is broken when {VirtProductName} is installed
|
||||
|
||||
@@ -44,7 +44,7 @@ When using Direct Image Migration (DIM), if a label selector is set on the migra
|
||||
[id="known-issues-1-8-4_{context}"]
|
||||
== Known issues
|
||||
|
||||
{mtc-full} ({mtc-short}) 1.8.4 has the following known issues:
|
||||
{mtc-short} 1.8.4 has the following known issues:
|
||||
|
||||
.The associated SCC for service account cannot be migrated in {OCP} 4.12
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
[id="resolved-issues-1-8_{context}"]
|
||||
== Resolved issues
|
||||
|
||||
{mtc-full} ({mtc-short}) 1.8.0 has the following resolved issues:
|
||||
{mtc-first} 1.8.0 has the following resolved issues:
|
||||
|
||||
.Indirect migration is stuck on backup stage
|
||||
|
||||
@@ -30,14 +30,14 @@ In previous releases, on an Azure cluster, when backing up to Azure storage, the
|
||||
[id="known-issues-1-8_{context}"]
|
||||
== Known issues
|
||||
|
||||
{mtc-full} ({mtc-short}) 1.8.0 has the following known issues:
|
||||
{mtc-short} 1.8.0 has the following known issues:
|
||||
|
||||
.Ansible Operator is broken when {VirtProductName} is installed
|
||||
|
||||
There is a bug in the `python3-openshift` package that installing {VirtProductName} exposes, with an exception `ValueError: too many values to unpack` returned during the task. {mtc-short} 1.8.4 has implemented a workaround. Updating to {mtc-short} 1.8.4 means you are no longer affected by this issue. link:https://issues.redhat.com/browse/OCPBUGS-38116[(OCPBUGS-38116)]
|
||||
|
||||
|
||||
.Old Restic pods are not getting removed on upgrading MTC 1.7.x -> 1.8.x
|
||||
.Old Restic pods are not getting removed on upgrading {mtc-short} 1.7.x -> 1.8.x
|
||||
|
||||
In this release, on upgrading the {mtc-short} Operator from 1.7.x to 1.8.x, the old Restic pods are not being removed. Therefore after the upgrade, both Restic and node-agent pods are visible in the namespace. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2236829[(BZ#2236829)])
|
||||
|
||||
@@ -80,16 +80,16 @@ For more details, see link:https://access.redhat.com/security/cve/cve-2022-25883
|
||||
|
||||
This release has the following technical changes:
|
||||
|
||||
* Migration from {product-title} 3 to {product-title} 4 requires a legacy {mtc-full} ({mtc-short}) Operator and {mtc-short} 1.7.x.
|
||||
* Migration from {product-title} 3 to {product-title} 4 requires a legacy {mtc-full} Operator and {mtc-full} 1.7.x.
|
||||
* Migration from {mtc-short} 1.7.x to {mtc-short} 1.8.x is not supported.
|
||||
* You must use {mtc-short} 1.7.x to migrate anything with a source of {product-title} 4.9 or earlier.
|
||||
** {mtc-short} 1.7.x must be used on both source and destination.
|
||||
* MTC 1.8.x only supports migrations from {product-title} 4.10 or later to {product-title} 4.10 or later. For migrations only involving cluster versions 4.10 and later, either 1.7.x or 1.8.x might be used. However, but it must be the same MTC 1.Y.z on both source and destination.
|
||||
* {mtc-first} 1.8.x only supports migrations from {product-title} 4.10 or later to {product-title} 4.10 or later. For migrations only involving cluster versions 4.10 and later, either 1.7.x or 1.8.x might be used. However, but it must be the same {mtc-short} 1.Y.z on both source and destination.
|
||||
** Migration from source {mtc-short} 1.7.x to destination {mtc-short} 1.8.x is unsupported.
|
||||
** Migration from source {mtc-short} 1.8.x to destination {mtc-short} 1.7.x is unsupported.
|
||||
** Migration from source {mtc-short} 1.7.x to destination {mtc-short} 1.7.x is supported.
|
||||
** Migration from source {mtc-short} 1.8.x to destination {mtc-short} 1.8.x is supported.
|
||||
* MTC 1.8.x by default installs OADP 1.2.x.
|
||||
* {mtc-short} 1.8.x by default installs OADP 1.2.x.
|
||||
* Upgrading from {mtc-short} 1.7.x to {mtc-short} 1.8.0, requires manually changing the OADP channel to 1.2. If this is not done, the upgrade of the Operator fails.
|
||||
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
[id="migration-mtc-workflow_{context}"]
|
||||
= {mtc-short} workflow
|
||||
|
||||
You can migrate Kubernetes resources, persistent volume data, and internal container images to {product-title} {product-version} by using the {mtc-full} ({mtc-short}) web console or the Kubernetes API.
|
||||
You can migrate Kubernetes resources, persistent volume data, and internal container images to {product-title} {product-version} by using the {mtc-first} web console or the Kubernetes API.
|
||||
|
||||
{mtc-short} migrates the following resources:
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="migration-rolling-back-migration-web-console_{context}"]
|
||||
= Rolling back a migration by using the {mtc-short} web console
|
||||
|
||||
You can roll back a migration by using the {mtc-full} ({mtc-short}) web console.
|
||||
You can roll back a migration by using the {mtc-first} web console.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="migration-running-migration-plan-cam_{context}"]
|
||||
= Running a migration plan in the {mtc-short} web console
|
||||
|
||||
You can migrate applications and data with the migration plan you created in the {mtc-full} ({mtc-short}) web console.
|
||||
You can migrate applications and data with the migration plan you created in the {mtc-first} web console.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="migration-state-migration-cli_{context}"]
|
||||
= State migration
|
||||
|
||||
You can perform repeatable, state-only migrations by using {mtc-full} ({mtc-short}) to migrate persistent volume claims (PVCs) that constitute an application's state. You migrate specified PVCs by excluding other PVCs from the migration plan. You can map the PVCs to ensure that the source and the target PVCs are synchronized. Persistent volume (PV) data is copied to the target cluster. The PV references are not moved, and the application pods continue to run on the source cluster.
|
||||
You can perform repeatable, state-only migrations by using {mtc-first} to migrate persistent volume claims (PVCs) that constitute an application's state. You migrate specified PVCs by excluding other PVCs from the migration plan. You can map the PVCs to ensure that the source and the target PVCs are synchronized. Persistent volume (PV) data is copied to the target cluster. The PV references are not moved, and the application pods continue to run on the source cluster.
|
||||
|
||||
State migration is specifically designed to be used in conjunction with external CD mechanisms, such as OpenShift Gitops. You can migrate application manifests using GitOps while migrating the state using {mtc-short}.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="migration-understanding-data-copy-methods_{context}"]
|
||||
= About data copy methods
|
||||
|
||||
The {mtc-full} ({mtc-short}) supports the file system and snapshot data copy methods for migrating data from the source cluster to the target cluster. You can select a method that is suited for your environment and is supported by your storage provider.
|
||||
The {mtc-first} supports the file system and snapshot data copy methods for migrating data from the source cluster to the target cluster. You can select a method that is suited for your environment and is supported by your storage provider.
|
||||
|
||||
[id="file-system-copy-method_{context}"]
|
||||
== File system copy method
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
[id="migration-uninstalling-mtc-clean-up_{context}"]
|
||||
= Uninstalling {mtc-short} and deleting resources
|
||||
|
||||
You can uninstall the {mtc-full} ({mtc-short}) and delete its resources to clean up the cluster.
|
||||
You can uninstall the {mtc-first} and delete its resources to clean up the cluster.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="migration-upgrading-from-mtc-1-3_{context}"]
|
||||
= Upgrading {mtc-short} 1.3 to {mtc-version}
|
||||
|
||||
If you are upgrading {mtc-full} ({mtc-short}) version 1.3.x to {mtc-version}, you must update the `MigPlan` custom resource (CR) manifest on the cluster on which the `MigrationController` pod is running.
|
||||
If you are upgrading {mtc-first} version 1.3.x to {mtc-version}, you must update the `MigPlan` custom resource (CR) manifest on the cluster on which the `MigrationController` pod is running.
|
||||
|
||||
Because the `indirectImageMigration` and `indirectVolumeMigration` parameters do not exist in {mtc-short} 1.3, their default value in version 1.4 is `false`, which means that direct image migration and direct volume migration are enabled. Because the direct migration requirements are not fulfilled, the migration plan cannot reach a `Ready` state unless these parameter values are changed to `true`.
|
||||
|
||||
@@ -15,7 +15,7 @@ Because the `indirectImageMigration` and `indirectVolumeMigration` parameters do
|
||||
|
||||
====
|
||||
* Migrating from {product-title} 3 to {product-title} 4 requires a legacy {mtc-short} Operator and {mtc-short} 1.7.x.
|
||||
* Upgrading MTC 1.7.x to 1.8.x requires manually updating the OADP channel from `stable-1.0` to `stable-1.2` in order to successfully complete the upgrade from 1.7.x to 1.8.x.
|
||||
* Upgrading {mtc-short} 1.7.x to 1.8.x requires manually updating the OADP channel from `stable-1.0` to `stable-1.2` in order to successfully complete the upgrade from 1.7.x to 1.8.x.
|
||||
====
|
||||
|
||||
.Prerequisites
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="migration-upgrading-mtc-on-ocp-4_{context}"]
|
||||
= Upgrading the {mtc-full} on {product-title} {product-version}
|
||||
|
||||
You can upgrade the {mtc-full} ({mtc-short}) on {product-title} {product-version} by using the Operator Lifecycle Manager.
|
||||
You can upgrade the {mtc-first} on {product-title} {product-version} by using the Operator Lifecycle Manager.
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
@@ -19,7 +19,7 @@ When upgrading the {mtc-short} by using the Operator Lifecycle Manager, you must
|
||||
* Migrating from {mtc-short} 1.7.x to {mtc-short} 1.8.x is not supported.
|
||||
* You must use {mtc-short} 1.7.x to migrate anything with a source of {product-title} 4.9 or earlier.
|
||||
** {mtc-short} 1.7.x must be used on both source and destination.
|
||||
* MTC 1.8.x only supports migrations from {product-title} 4.10 or later to {product-title} 4.10 or later. For migrations only involving cluster versions 4.10 and later, either 1.7.x or 1.8.x may be used. However, it must be the same MTC version on both source & destination.
|
||||
* {mtc-short} 1.8.x only supports migrations from {product-title} 4.10 or later to {product-title} 4.10 or later. For migrations only involving cluster versions 4.10 and later, either 1.7.x or 1.8.x may be used. However, it must be the same {mtc-short} version on both source & destination.
|
||||
** Migration from source {mtc-short} 1.7.x to destination {mtc-short} 1.8.x is unsupported.
|
||||
** Migration from source {mtc-short} 1.8.x to destination {mtc-short} 1.7.x is unsupported.
|
||||
** Migration from source {mtc-short} 1.7.x to destination {mtc-short} 1.7.x is supported.
|
||||
|
||||
@@ -8,12 +8,12 @@
|
||||
ifdef::upgrading-3-4[]
|
||||
= Upgrading the {mtc-full} on {product-title} 3
|
||||
|
||||
You can upgrade {mtc-full} ({mtc-short}) on {product-title} 3 by manually installing the legacy {mtc-full} Operator.
|
||||
You can upgrade {mtc-first} on {product-title} 3 by manually installing the legacy {mtc-full} Operator.
|
||||
endif::[]
|
||||
ifdef::upgrading-mtc[]
|
||||
= Upgrading the {mtc-full} on {product-title} versions 4.2 to 4.5
|
||||
|
||||
You can upgrade {mtc-full} ({mtc-short}) on {product-title} versions 4.2 to 4.5 by manually installing the legacy {mtc-full} Operator.
|
||||
You can upgrade {mtc-first} on {product-title} versions 4.2 to 4.5 by manually installing the legacy {mtc-full} Operator.
|
||||
endif::[]
|
||||
|
||||
.Prerequisites
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="migration-using-mtc-crs-for-troubleshooting_{context}"]
|
||||
= Using {mtc-short} custom resources for troubleshooting
|
||||
|
||||
You can check the following {mtc-full} ({mtc-short}) custom resources (CRs) to troubleshoot a failed migration:
|
||||
You can check the following {mtc-first} custom resources (CRs) to troubleshoot a failed migration:
|
||||
|
||||
* `MigCluster`
|
||||
* `MigStorage`
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
[id="mtc-mig-cluster-configuration_{context}"]
|
||||
= MigCluster Configuration
|
||||
|
||||
For every `MigCluster` resource created in MTC, a `ConfigMap` named `migration-cluster-config` is created in the Migration Operator's namespace on the cluster which MigCluster resource represents.
|
||||
For every `MigCluster` resource created in {mtc-first}, a `ConfigMap` named `migration-cluster-config` is created in the Migration Operator's namespace on the cluster which MigCluster resource represents.
|
||||
|
||||
The `migration-cluster-config` allows you to configure MigCluster specific values. The Migration Operator manages the `migration-cluster-config`.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="oadp-about-backing-and-restoring-from-cluster-to-cluster_{context}"]
|
||||
= About backing up data from one cluster and restoring it on another cluster
|
||||
|
||||
{oadp-first} is designed to back up and restore application data in the same {product-title} cluster. {mtc-full} ({mtc-short}) is designed to migrate containers, including application data, from one {product-title} cluster to another cluster.
|
||||
{oadp-first} is designed to back up and restore application data in the same {product-title} cluster. {mtc-first} is designed to migrate containers, including application data, from one {product-title} cluster to another cluster.
|
||||
|
||||
You can use OADP to back up application data from one {product-title} cluster and restore it on another cluster. However, doing so is more complicated than using {mtc-short} or using OADP to back up and restore on the same cluster.
|
||||
|
||||
|
||||
@@ -11,6 +11,6 @@ Storage class mapping allows you to define rules or policies specifying which st
|
||||
You can use the `change-storage-class-config` field to change the storage class of your data objects, which lets you optimize costs and performance by moving data between different storage tiers, such as from standard to archival storage, based on your needs and access patterns.
|
||||
|
||||
[id=storage-class-mapping-mtc_{context}]
|
||||
== Storage class mapping with MTC
|
||||
== Storage class mapping with {mtc-full}
|
||||
|
||||
You can use the Migration Toolkit for Containers (MTC) to migrate containers, including application data, from one {product-title} cluster to another cluster and for storage class mapping and conversion. You can convert the storage class of a persistent volume (PV) by migrating it within the same cluster. To do so, you must create and run a migration plan in the MTC web console.
|
||||
You can use the {mtc-first} to migrate containers, including application data, from one {product-title} cluster to another cluster and for storage class mapping and conversion. You can convert the storage class of a persistent volume (PV) by migrating it within the same cluster. To do so, you must create and run a migration plan in the {mtc-short} web console.
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
{OCP} environments have the `PodSecurityAdmission` controller enabled by default. This controller requires cluster administrators to enforce Pod Security Standards by means of namespace labels. All workloads in the cluster are expected to run one of the following Pod Security Standard levels: `Privileged`, `Baseline` or `Restricted`. Every cluster has its own default policy set.
|
||||
|
||||
To guarantee successful data transfer in all environments, {mtc-full} ({mtc-short}) 1.7.5 introduced changes in Rsync pods, including running Rsync pods as non-root user by default. This ensures that data transfer is possible even for workloads that do not necessarily require higher privileges. This change was made because it is best to run workloads with the lowest level of privileges possible.
|
||||
To guarantee successful data transfer in all environments, {mtc-first} 1.7.5 introduced changes in Rsync pods, including running Rsync pods as non-root user by default. This ensures that data transfer is possible even for workloads that do not necessarily require higher privileges. This change was made because it is best to run workloads with the lowest level of privileges possible.
|
||||
|
||||
[id="manually-overriding-default-nonroot-operation_{context}"]
|
||||
== Manually overriding default non-root operation for data transfer
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
[id="relabeling-selinux-workaround_{context}"]
|
||||
= Applying the Skip SELinux relabel workaround with `spc_t` automatically on workloads running on {OCP}
|
||||
|
||||
When attempting to migrate a namespace with {mtc-full} ({mtc-short}) and a substantial volume associated with it, the `rsync-server` may become frozen without any further information to troubleshoot the issue.
|
||||
When attempting to migrate a namespace with {mtc-first} and a substantial volume associated with it, the `rsync-server` may become frozen without any further information to troubleshoot the issue.
|
||||
|
||||
[id="diagnosis-selinux-workaround_{context}"]
|
||||
== Diagnosing the need for the Skip SELinux relabel workaround
|
||||
|
||||
@@ -21,7 +21,7 @@ $ oc -n openshift-migration patch subscription redhat-oadp-operator-stable-1.0-m
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
Sections indicating the user-specific returned `NAME` values that are used for the installation of MTC & OADP, respectively.
|
||||
Sections indicating the user-specific returned `NAME` values that are used for the installation of {mtc-short} & OADP, respectively.
|
||||
====
|
||||
+
|
||||
.Example output
|
||||
|
||||
@@ -11,5 +11,5 @@
|
||||
:_mod-docs-content-type: SNIPPET
|
||||
[NOTE]
|
||||
====
|
||||
Starting from OADP 1.0.4, all OADP 1.0._z_ versions can only be used as a dependency of the MTC Operator and are not available as a standalone Operator.
|
||||
Starting from OADP 1.0.4, all OADP 1.0._z_ versions can only be used as a dependency of the {mtc-full} Operator and are not available as a standalone Operator.
|
||||
====
|
||||
|
||||
Reference in New Issue
Block a user