Merge pull request #43802 from mjpytlak/revert-42576-MIG-1078

Revert "MIG-1078: Update MTC 1.7 Compatibility guidelines"

Author: bergerhoffer

_attributes/common-attributes.adoc

@@ -46,7 +46,7 @@ endif::[]
 :launch: image:app-launcher.png[title="Application Launcher"]
 :mtc-short: MTC
 :mtc-full: Migration Toolkit for Containers
-:mtc-version: 1.7
+:mtc-version: 1.6
 :mtc-legacy-version: 1.5
 :mtc-legacy-version-z: 1.5.3
 //gitops

modules/migration-compatibility-guidelines.adoc

@@ -5,51 +5,21 @@
 // * migration_toolkit_for_containers/installing-mtc.adoc
 // * migration_toolkit_for_containers/installing-mtc-restricted.adoc
 
-:_content-type: CONCEPT
 [id="migration-compatibility-guidelines_{context}"]
 = Compatibility guidelines
 
 You must install the {mtc-full} ({mtc-short}) Operator that is compatible with your {product-title} version.
 
-.Definitions
+You cannot install {mtc-short} {mtc-version} on {product-title} 4.5, or earlier versions, because the custom resource definition API versions are incompatible.
 
-legacy platform:: {product-title} 4.5 and earlier.
-modern platform:: {product-title} 4.6 and later.
-legacy operator:: The {mtc-short} Operator designed for legacy platforms.
-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 can migrate workloads from a source cluster with {mtc-short} {mtc-legacy-version-z} to a target cluster with {mtc-short} {mtc-version} as long as the `MigrationController` custom resource and the {mtc-short} web console are running on the target cluster.
 
-
-[cols="1,2,2", options="header"]
-.{mtc-short} compatibility: Migrating from a legacy platform
+[cols="1,1,2", options="header"]
+.{product-title} and {mtc-short} compatibility
 |===
-||{product-title} 4.5 or earlier |{product-title} 4.6 later
-|Latest {mtc-short} version a|{mtc-short} {mtc-version}.z
-
-Legacy {mtc-version} operator: Install manually with the `operator.yml` file.
-[IMPORTANT]
-====
-This cluster cannot be the control cluster.
-====
-
-|{mtc-short} {mtc-version}.z
-
-Install with OLM, release channel `release-v1.7`
-|Stable {mtc-short} version |{mtc-short} 1.5
+|{product-title} version |{mtc-short} version |{mtc-full} Operator
 
-Legacy 1.5 operator: Install manually with the `operator.yml` file.
+|4.5 and earlier |{mtc-legacy-version-z} |Legacy {mtc-full} Operator, installed manually with the `operator.yml` file.
 
-|{mtc-short} 1.6.z
-
-Install with OLM, release channel `release-v1.6`
+|4.6 and later |Latest {mtc-version}.x z-stream release |{mtc-full} Operator, installed with Operator Lifecycle Manager.
 |===
-
-[NOTE]
-====
-Edge cases exist in which network restrictions prevent modern clusters from connecting to other clusters involved in the migration. For example, when migrating from an {product-title} 3.11 cluster on premises to a modern {product-title} cluster in the cloud, where the modern cluster cannot connect to the {product-title} 3.11 cluster.
-
-With {mtc-short} {mtc-version}, if one of the remote clusters is unable to communicate with the control cluster because of network restrictions, use the `crane tunnel-api` command.
-
-With the stable {mtc-short} release, although you should always designate the most modern cluster as the control cluster, in this specific case it is possible to designate the legacy cluster as the control cluster and push workloads to the remote cluster.
-====