Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 4. MTA 7-0-1
4.1. Known issues
Migration Toolkit for Applications (MTA) version 7.0.1 has the following issues.
MTA CLI does not function on machines using ARM based architecture
MTA CLI does not function on machines using ARM based architecture. The workaround is to use the upstream images, which will function as expected as they are built using multi-arch. To do this, issue:
RUNNER_IMG=quay.io/konveyor/kantra:latest CMD_NAME=kantra ./mta-cli analyze ...
Delayed permission update and user deactivation in RBAC
When deleting, deactivating or degrading the role of a user, such as changing the user from Admin to Migrator, the change can take several minutes to take effect. This delay in changing the user status can pose an operational or security risk. MTA-1809
Re-enabling Keycloak breaks MTA
Keycloak is enabled by default. If you disable and then re-enable Keycloak, you cannot perform any actions in the MTA web console after logging in again.
This error is caused as the credential-mta-rhsso secret is updated when auth/Keycloak is disabled and re-enabled.
The suggested workaround is to restore the old password in the credential-mta-rhsso secret, after re-enabling auth. MTA-1152
org.apache.derby.derby dependency not analyzed
The org.apache.derby.derby dependency is not analyzed. MTA-1817
Redundant warning on reassessment of applications with inherited assessments
The system repeatedly shows a warning message about overriding an inherited assessment when reassessing an application.
This warning, appropriate for the first assessment, incorrectly reappears on subsequent reassessments, suggesting that the application is still inheriting its assessment, even after it has been overridden. MTA-1825
For a complete list of all known issues in this release, see the list of Known Issues in Jira.
4.1.1. CLI known issues
Limitations with Podman on Microsoft Windows
The CLI is built and distributed with support for Microsoft Windows.
However, when running any container image based on Red Hat Enterprise Linux 9 (RHEL9) or Universal Base Image 9 (UBI9), the following error can be returned when starting the container:
Fatal glibc error: CPU does not support x86-64-v2
This error is caused because Red Hat Enterprise Linux 9 or Universal Base Image 9 container images must be run on a CPU architecture that supports x86-64-v2.
For more details, see (Running Red Hat Enterprise Linux 9 (RHEL) or Universal Base Image (UBI) 9 container images fail with "Fatal glibc error: CPU does not support x86-64-v2").
CLI runs the container runtime correctly. However, different container runtime configurations are not supported.
Although unsupported, you can run CLI with Docker instead of Podman, which would resolve this issue.
To achieve this, you replace the PODMAN_BIN path with the path to Docker.
For example, if you experience this issue, instead of issuing:
PODMAN_BIN=/usr/local/bin/docker mta-cli analyze
You replace PODMAN_BIN with the path to Docker:
<Docker Root Dir>=/usr/local/bin/docker mta-cli analyze
While this is not supported, it would allow you to explore CLI while you work to upgrade your hardware or move to hardware that supports x86_64-v2.
4.2. Resolved issues
The following highlighted issues have been resolved in Migration Toolkit for Applications (MTA) version 7.0.1.
Pathfinder assessment migration fails on upgrade from MTA 6.2.1 to MTA 7.0.0
In previous version of MTA 7.0.0, when MTA 6.2.1 is installed, and you attempt to switch the channel to stable-7.0, the operator upgrade succeeds, but a task in the operator pod fails. This failure resulted in existing pathfinder assessments not being migrated to MTA 7.0.0. This bug is resolved in MTA 7.0.1. MTA-2139
For a complete list of all issues resolved in this release, see the list of Resolved Issues in Jira.
4.3. Upgrade notes
The following are upgrade notes for Migration Toolkit for Applications (MTA)
Upgrade from MTA 6.2.1 to MTA 7.0.1
Upgrade directly from MTA 6.2.1 to MTA 7.0.1.
Pathfinder assessment migration fails on upgrade from MTA 6.2.1 to MTA 7.0.0
In previous version of MTA 7.0.0, when MTA 6.2.1 is installed, and you attempt to switch the channel to stable-7.0, the operator upgrade succeeds, but a task in the operator pod fails. This failure resulted in existing pathfinder assessments not being migrated to MTA 7.0.0. As this bug has been resolved in MTA 7.0.1, it is suggested to upgrade directly from MTA 6.2.1 to MTA 7.0.1. MTA-2139
On upgrading from MTA 6.2.1 to MTA 7.0.1 , completed assessment are shown as In progress. Enable the legacy Pathfinder questionnaire to see the completed status of assessment.
Hub database volume size
In version 7.0.1 of MTA, the default size of the hub database volume has been increased to 10GiB.
If your storage class does not support volume expansion, then an upgrade from 6.2.1 to 7.0.1 will result in a failure due to the operator trying to change the volume size from 5GiB to 10GiB.
To avoid this issue, you can directly set the volume size by setting:
... hub_database_volume_size: 5Gi ...
By doing this, you will avoid the operator trying to resize the volume.
If this value was set when the previous version was deployed, there is no need to take any action, as it will work as expected.
Existing data
When upgrading to MTA 7.0.0, all existing data will be retained, except for individual analysis reports for applications.
As both the analysis and reporting engines have been replaced with this version, you will be required to conduct a re-run of the analysis in order to obtain data on issues and dependencies.
