Chapter 3. Installing the Migration Toolkit for Applications user interface
You install the Migration Toolkit for Applications (MTA) user interface as part of the process of installing the MTA Operator on the OpenShift Container Platform.
The MTA Operator is a structural layer that manages resources deployed on Kubernetes (database, front end, back end) to automatically create an MTA instance instead of you doing it manually.
3.1. Persistent volume requirements
To successfully deploy, the MTA Operator requires 3 RWO persistent volumes (PVs) used by different components. If the rwx_supported
configuration option is set to true
, the MTA Operator requires an additional 2 RWX PVs that are used by Maven and the hub file storage. The PVs are described in the table below:
Name | Default size | Access mode | Description |
---|---|---|---|
| 5 GiB | RWO | Hub database |
| 100 GiB | RWX |
Hub file storage; required if the |
| 1 GiB | RWO | Keycloak back end database |
| 1 GiB | RWO | Pathfinder back end database |
| 100 GiB | RWX |
Maven m2 cache; required if the |
3.2. Installing the Migration Toolkit for Applications Operator and the user interface
You can install the Migration Toolkit for Applications (MTA) and the user interface on OpenShift Container Platform versions 4.12-4.14 when you install the Migration Toolkit for Applications Operator.
Prerequisites
- 4 vCPUs, 8 GiB RAM, and 40 GB persistent storage.
- OpenShift Container Platform 4.12-4.14 installed.
-
You must be logged in as a user with
cluster-admin
permissions.
Procedure
-
In the OpenShift Container Platform web console, click Operators
OperatorHub. - Use the Filter by keyword field to search for MTA.
- Click the Migration Toolkit for Applications Operator and then click Install.
- On the Install Operator page, click Install.
-
Click Operators
Installed Operators to verify that the MTA Operator appears in the openshift-mta
project with the statusSucceeded
. - Click the MTA Operator.
Under Provided APIs, locate Tackle, and click Create Instance.
The Create Tackle window opens in Form view.
- Review the CR settings. The default choices should be acceptable, but make sure to check the system requirements for storage, memory, and cores.
To work directly with the YAML file, click YAML view and review the CR settings that are listed in the
spec
section of the YAML file.The most commonly used CR settings are listed in this table:
Table 3.2. Tackle CR settings Name Default Description cache_data_volume_size
100 GiB
Size requested for the cache volume; ignored when
rwx_supported=false
cache_storage_class
Default storage class
Storage class used for the cache volume; ignored when
rwx_supported=false
feature_auth_required
True
Flag to indicate whether keycloak authorization is required (single user/“noauth”)
feature_isolate_namespace
True
Flag to indicate whether namespace isolation using network policies is enabled
hub_database_volume_size
5 GiB
Size requested for the Hub database volume
hub_bucket_volume_size
100 GiB
Size requested for the Hub bucket volume
hub_bucket_storage_class
Default storage class
Storage class used for the bucket volume
keycloak_database_data_volume_size
1 GiB
Size requested for the Keycloak database volume
pathfinder_database_data_volume_size
1 GiB
Size requested for the Pathfinder database volume
maven_data_volume_size
100 GiB
Size requested for the Maven m2 cache volume; deprecated in MTA 6.0.1
rwx_storage_class
NA
Storage class requested for the Tackle RWX volumes; deprecated in MTA 6.0.1
rwx_supported
True
Flag to indicate whether the cluster storage supports RWX mode
rwo_storage_class
NA
Storage class requested for the Tackle RW0 volumes
rhsso_external_access
False
Flag to indicate whether a dedicated route is created to access the MTA managed RHSSO instance
windup_container_limits_cpu
1
Maximum number of CPUs the pod is allowed to use
windup_container_limits_memory
6Gi
Maximum amount of memory the pod is allowed to use. You can increase this limit if the pod displays
OOMKilled
errors.windup_container_requests_cpu
1
Minimum number of CPUs the pod needs to run
windup_container_requests_memory
4Gi
Minimum amount of memory the pod needs to run
Example YAML file
kind: Tackle apiVersion: tackle.konveyor.io/v1alpha1 metadata: name: mta namespace: openshift-mta spec: hub_bucket_volume_size: "25Gi" maven_data_volume_size: "25Gi" rwx_supported: "false"
- Edit the CR settings if needed, and then click Create.
-
In Administration view, click Workloads
Pods to verify that the MTA pods are running. -
Access the user interface from your browser by using the route exposed by the
mta-ui
application within OpenShift. Use the following credentials to log in:
- User name: admin
- Password: Passw0rd!
- When prompted, create a new password.
3.3. Installing the Migration Toolkit for Applications Operator in a disconnected OpenShift Container Platform environment
You can install the MTA Operator in a disconnected environment by following the generic procedure.
In step 1 of the generic procedure, configure the image set for mirroring as follows:
kind: ImageSetConfiguration apiVersion: mirror.openshift.io/v1alpha2 storageConfig: registry: imageURL: registry.to.mirror.to skipTLS: false mirror: operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.12 packages: - name: mta-operator channels: - name: stable-v6.1 - name: rhsso-operator channels: - name: stable helm: {}
3.4. Memory requirements for running MTA on Red Hat OpenShift Local
When installed on Red Hat OpenShift Local, MTA requires a minimum amount of memory to complete its analysis. Adding memory above the required minimum makes the analysis process run faster. The table below describes the MTA performance with varying amounts of memory.
Memory (GiB) | Description |
---|---|
| MTA cannot run the analysis due to insufficient memory |
| MTA cannot run the analysis due to insufficient memory |
| MTA works and the analysis is completed in approximately 3 minutes |
| MTA works and the analysis is completed in less than 2 minutes |
| MTA works quickly and the analysis is completed in less than 1 minute |
The test results indicate that the minimum amount of memory for running MTA on OpenShift Local is 12 GiB.
- The tests were performed by running the MTA binary analysis through the user interface.
-
All the analyses used the
tackle-testapp
binary. - All the tests were conducted on an OpenShift Local cluster without the monitoring tools installed.
- Installing the cluster monitoring tools requires an additional 5 GiB of memory.
3.4.1. Eviction threshold
Each node has a certain amount of memory allocated to it. Some of that memory is reserved for system services. The rest of the memory is intended for running pods. If the pods use more than their allocated amount of memory, an out-of-memory event is triggered and the node is terminated with a OOMKilled
error.
To prevent out-of-memory events and protect nodes, use the --eviction-hard
setting. This setting specifies the threshold of memory availability below which the node evicts pods. The value of the setting can be absolute or a percentage.
Example of node memory allocation settings
-
Node capacity:
32 Gi
-
--system-reserved
setting:3 Gi
-
--eviction-hard
setting:100 Mi
The amount of memory available for running pods on this node is 28.9 Gi. This amount is calculated by subtracting the system-reserved
and eviction-hard
values from the overall capacity of the node. If the memory usage exceeds this amount, the node starts evicting pods.
3.5. Red Hat Single Sign-On
MTA delegates authentication and authorization to a Red Hat Single Sign-On (RHSSO) instance managed by the MTA operator. Aside from controlling the full lifecycle of the managed RHSSO instance, the MTA operator also manages the configuration of a dedicated realm that contains all the roles and permissions that MTA requires.
If an advanced configuration is required in the MTA managed RHSSO instance, such as adding a provider for User Federation or integrating identity providers, users can log into the RHSSO Admin Console through the /auth/admin
subpath in the mta-ui
route. The admin credentials to access the MTA managed RHSSO instance can be retrieved from the credential-mta-rhsso
secret available in the namespace in which the user interface was installed.
A dedicated route for the MTA managed RHSSO instance can be created by setting the rhsso_external_access
parameter to True
in the Tackle CR that manages the MTA instance.
For more information, see Red Hat Single Sign-On features and concepts.
3.5.1. Roles and Permissions
The following table contains the roles and permissions (scopes) that MTA seeds the managed RHSSO instance with:
tackle-admin | Resource Name | Verbs |
addons |
delete | |
adoptionplans |
post | |
applications |
delete | |
applications.facts |
delete | |
applications.tags |
delete | |
applications.bucket |
delete | |
assessments |
delete | |
businessservices |
delete | |
dependencies |
delete | |
identities |
delete | |
imports |
delete | |
jobfunctions |
delete | |
proxies |
delete | |
reviews |
delete | |
settings |
delete | |
stakeholdergroups |
delete | |
stakeholders |
delete | |
tags |
delete | |
tagtypes |
delete | |
tasks |
delete | |
tasks.bucket |
delete | |
tickets |
delete | |
trackers |
delete | |
cache |
delete | |
files |
delete | |
rulebundles |
delete | |
tackle-architect | Resource Name | Verbs |
addons |
delete | |
applications.bucket |
delete | |
adoptionplans |
post | |
applications |
delete | |
applications.facts |
delete | |
applications.tags |
delete | |
assessments |
delete | |
businessservices |
delete | |
dependencies |
delete | |
identities |
get | |
imports |
delete | |
jobfunctions |
delete | |
proxies |
get | |
reviews |
delete | |
settings |
get | |
stakeholdergroups |
delete | |
stakeholders |
delete | |
tags |
delete | |
tagtypes |
delete | |
tasks |
delete | |
tasks.bucket |
delete | |
trackers |
get | |
tickets |
delete | |
cache |
get | |
files |
delete | |
rulebundles |
delete | |
tackle-migrator | Resource Name | Verbs |
addons |
get | |
adoptionplans |
post | |
applications |
get | |
applications.facts |
get | |
applications.tags |
get | |
applications.bucket |
get | |
assessments |
get | |
businessservices |
get | |
dependencies |
delete | |
identities |
get | |
imports |
get | |
jobfunctions |
get | |
proxies |
get | |
reviews |
get | |
settings |
get | |
stakeholdergroups |
get | |
stakeholders |
get | |
tags |
get | |
tagtypes |
get | |
tasks |
delete | |
tasks.bucket |
delete | |
tackers |
get | |
tickets |
get | |
cache |
get | |
files |
get | |
rulebundles |
get |