|
| 1 | +// Module included in the following assemblies: |
| 2 | +// |
| 3 | +// * migration_toolkit_for_containers/mtc-release-notes.adoc |
| 4 | +:_mod-docs-content-type: REFERENCE |
| 5 | +[id="migration-mtc-release-notes-1-8-6_{context}"] |
| 6 | += {mtc-full} 1.8.6 release notes |
| 7 | + |
| 8 | +[id="technical-changes-1-8-6_{context}"] |
| 9 | +== Technical changes |
| 10 | + |
| 11 | +.Multiple migration plans for a namespace is not supported |
| 12 | + |
| 13 | +{mtc-short} version 1.8.6 and later do not support multiple migration plans for a single namespace. |
| 14 | + |
| 15 | +.VM storage migration |
| 16 | + |
| 17 | +VM storage migration feature changes from Technology Preview (TP) status to being Generally Available (GA). |
| 18 | + |
| 19 | +[id="resolved-issues-1-8-6_{context}"] |
| 20 | +== Resolved issues |
| 21 | + |
| 22 | +{mtc-short} 1.8.6 has the following major resolved issues: |
| 23 | + |
| 24 | +.UI crashes during a namespace search in the migration plan wizard |
| 25 | + |
| 26 | +When searching for a namespace in the *Select Namespace* step of the migration plan wizard, the user interface (UI) crashes and disappears after clicking *Search*. The browser console shows a JavaScript error indicating that an undefined value has been accessed. This issue has been resolved in {mtc-short} 1.8.6. link:https://issues.redhat.com/browse/MIG-1704[(MIG-1704)] |
| 27 | + |
| 28 | +.Unable to create a migration plan due to a reconciliation failure |
| 29 | + |
| 30 | +When creating a migration plan in {mtc-short}, the UI becomes stuck on the *Persistent Volumes* and you cannot continue. This issue occurs due to a critical reconciliation failure and returns a 404 API error when you attempt to fetch the migration plan from the backend. These issues cause the migration plan to remain in a *Not Ready* state, and you are prevented from continuing. This issue has been resolved in {mtc-short} 1.8.6. link:https://issues.redhat.com/browse/MIG-1705[(MIG-1705)] |
| 31 | + |
| 32 | +.Migration process becomes stuck after the `StageBackup` phase |
| 33 | + |
| 34 | +When migrating a Django and PostgreSQL application, the migration becomes stuck after the `StageBackup` phase. Even though all the pods in the source namespace are healthy before the migration begins, after the migration and when terminating the pods on the source cluster, the Django pod fails with a `CrashLoopBackOff` error. This issue has been resolved in {mtc-short} 1.8.6. link:https://issues.redhat.com/browse/MIG-1707[(MIG-1707)] |
| 35 | + |
| 36 | +.Migration shown as succeeded despite a failed phase due to a misleading UI status |
| 37 | + |
| 38 | +After running a migration using {mtc-short}, the UI incorrectly indicates that the migration was successful, with the status shown as *Migration succeeded*. However, the Direct Volume Migration (DVM) phase failed. This misleading status appears on both the *Migration* and the *Migration Details* pages. This issue has been resolved in {mtc-short} 1.8.6. link:https://issues.redhat.com/browse/MIG-1711[(MIG-1711)] |
| 39 | + |
| 40 | +[id="known-issues-1-8-6_{context}"] |
| 41 | +== Known issues |
| 42 | + |
| 43 | +{mtc-short} 1.8.6 has the following known issues: |
| 44 | + |
| 45 | +.Inconsistent reporting of migration failure status |
| 46 | + |
| 47 | +There is a discrepancy in the reporting of namespace migration status following a rollback and subsequent re-migration attempt when the migration plan is deliberately faulted. Although the Distributed Volume Migration (DVM) phase correctly registers a failure, this failure is not consistently reflected in the user interface (UI) or the migration plan's YAML representation. link:https://issues.redhat.com/browse/MIG-1719[(MIG-1719)] |
0 commit comments