Merge pull request #65437 from anarnold97/mig1418rnfix

Author: adellape

migration_toolkit_for_containers/mtc-release-notes.adoc

@@ -17,6 +17,7 @@ You can migrate from xref:../migrating_from_ocp_3_to_4/about-migrating-from-3-to
 
 For information on the support policy for {mtc-short}, see link:https://access.redhat.com/support/policy/updates/openshift#app_migration[OpenShift Application and Cluster Migration Solutions], part of the _Red Hat {product-title} Life Cycle Policy_.
 
+include::modules/migration-mtc-release-notes-1-8.adoc[leveloffset=+1]
 include::modules/migration-mtc-release-notes-1-7-12.adoc[leveloffset=+1]
 include::modules/migration-mtc-release-notes-1-7-11.adoc[leveloffset=+1]
 include::modules/migration-mtc-release-notes-1-7-10.adoc[leveloffset=+1]

modules/migration-mtc-release-notes-1-8.adoc

@@ -0,0 +1,67 @@
+
+// Module included in the following assemblies:
+//
+// * migration_toolkit_for_containers/mtc-release-notes.adoc
+:_content-type: REFERENCE
+[id="migration-mtc-release-notes-1-8_{context}"]
+= {mtc-full} 1.8 release notes
+
+[id="resolved-issues-1-8_{context}"]
+== Resolved issues
+
+This release has the following resolved issues:
+
+.Indirect migration is stuck on backup stage
+
+In previous releases, an indirect migration became stuck at the backup stage, due to `InvalidImageName` error.
+(link:https://bugzilla.redhat.com/show_bug.cgi?id=2233097[*BZ#2233097*])
+
+.PodVolumeRestore remain In Progress keeping the migration stuck at Stage Restore
+
+In previous releases, on performing an indirect migration, the migration became stuck at the `Stage Restore` step, waiting for the `podvolumerestore` to be completed. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2233868[*BZ#2233868*])
+
+.Migrated application unable to pull image from internal registry on target cluster
+
+In previous releases, on migrating an application to the target cluster, the migrated application failed to pull the image from the internal image registry resulting in an `application failure`. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2233103[*BZ#2233103*])
+
+.Migration failing on Azure due to authorization issue
+
+In previous releases, on an Azure cluster, when backing up to Azure storage, the migration failed at the `Backup` stage. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2238974[*BZ#2238974*])
+
+[id="known-issues-1-8_{context}"]
+== Known issues
+
+This release has the following known issues:
+
+.Old Restic pods are not getting removed on upgrading MTC 1.7.x -> 1.8.x
+
+In this release, on upgrading the MTC 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*])
+
+.Migrated builder pod fails to push to image registry
+
+In this release, on migrating an application including a `BuildConfig` from a source to target cluster, builder pod results in `error`, failing to push the image to the image registry. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2234781[*BZ#2234781*])
+
+.[UI] CA bundle file field is not properly cleared
+
+In this release, after enabling `Require SSL verification` and adding content to the CA bundle file for an MCG NooBaa bucket in MigStorage, the connection fails as expected. However, when reverting these changes by removing the CA bundle content and clearing `Require SSL verification`, the connection still fails. The issue is only resolved by deleting and re-adding the repository. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2240052[*BZ#2240052*])
+
+
+[id="technical-changes-1-8_{context}"]
+== Technical changes
+
+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 {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.
+** 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.
+* 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.
+
+
+