Upgrading migration toolkit for applications
Upgrade MTA to include new features and deprecations.
Abstract
Making open source more inclusive
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.
Chapter 1. The migration toolkit for applications upgrade
As an administrator, you can upgrade the migration toolkit for applications (MTA) to the 8.2.0 version on your Red Hat OpenShift cluster. The MTA Operator is released every four months. You can check the MTA Operator release cadence for general availability, full support, and maintenance support lifecycle.
You can upgrade MTA in the following Red Hat OpenShift deployments:
- Red Hat OpenShift Service on AWS (ROSA)
- Azure Red Hat OpenShift (ARO)
- Red Hat OpenShift Container Platform
1.1. Upgrade strategy
When you install an earlier MTA version from the software catalog in your cluster, you must choose the manual update strategy that needs you to manually approve the install plan for the MTA Operator. For the latest version, automatic update is selected as the default upgrade strategy.
The upgrade strategy is applied to all operators that you install in the namespace. If you want separate upgrade strategies for operators, you must install the operators in a different namespace.
Additional resources
Chapter 2. Upgrade to migration toolkit for applications 8.2.0
As an administrator, you can upgrade the migration toolkit for applications (MTA) from the Installed Operators page of the Red Hat OpenShift console.
Prerequisites
- You reviewed the release notes for new features, enhancements, and known issues.
- You reviewed the persistent volume requirements.
- You backed up the data.
Procedure
- On the Red Hat OpenShift cluster, click Ecosystem > Installed Operators.
- Select your project from the project list where you installed MTA.
- Click the Upgrade available link in the Status column.
On the Install Plan page, click Preview Install Plan in the details tab.
The navigation switches to the components tab.
- Check the resource list for the upgrade version.
- Click Approve in the Review Manual Install Plan section of the components tab.
Verification
- Navigate to the Installed Operators page.
- The MTA Operator status for the old version changes to Replacing.
- The latest MTA Operator installs with status Succeeded.
Verify the updated version number under the operator name.
The old operator is automatically removed from the page.
Additional resources
Chapter 3. Migrate Keycloak users
As a Migration toolkit for applications (MTA) administrator, you can federate user authentication to your Keycloak instance and reduce configuration complexity when you upgrade to MTA 8.2.0.
When you upgrade to MTA 8.2.0, the MTA Operator finds the Red Hat build of Keycloak (RHBK) in the MTA namespace if you deployed Keycloak in earlier versions.
If RHBK is available, the MTA Operator installs a Keycloak Operator and deploys an IdentityProvider custom resource (CR) for your Keycloak instance.
In this case, the Keycloak Operator manages the RHBK instance and configures a dedicated realm with necessary roles and permissions. You can configure Keycloak as the primary authentication method in the MTA Tackle CR for an automatic redirect to your instance for user authentication. If you do not configure Keycloak as the primary authentication method, you can click the Sign-in with Keycloak option on the Hub login page to redirect authentication.
If you did not deploy an RHBK instance in the MTA namespace before the upgrade, or if you install MTA for the first time, the MTA Operator does not deploy the Keycloak Operator, PostgreSQL database, and other RHBK resources. You no longer need to provision 1 GiB for the Keycloak database volume in the MTA namespace.
In such cases, you can configure a Keycloak instance separately and integrate it as an identity provider (IdP) for user authentication in MTA. The Hub OpenID Connect (OIDC) provider federates user authentication to the Keycloak provider.
You can configure Keycloak as the OIDC provider by using the IdentityProvider CR and continue to manage users and roles in Keycloak.
You can configure the existing Keycloak instance as an IdP for user authentication by complete the following tasks:
Configure the IdP by using the
IdentityProviderCR.- Configure the Keycloak instance uniform resource identifier (URI) as the OIDC issuer in the CR.
- Configure the Hub URL with the callback endpoint as the redirect URI.
- Deploy the CR in the same namespace where you installed the MTA application in your cluster.
The MTA Operator reconfigures the Hub to federate OIDC to your existing Keycloak instance.
Additional resources
Chapter 4. Command-line updates
As an administrator, you must make necessary changes to your pipeline or scripts to include the updated migration toolkit for applications (MTA) command-line (CLI) commands and remove deprecated commands.
4.1. Deprecated CLI commands
The following commands and options are deprecated:
List sources
$ mta-cli analyze --list-sources
List targets
$ mta-cli analyze --list-targets
List providers
$ mta-cli analyze --list-providers
Test rulesets
$ mta-cli test <path_to_ruleset>Transform
$ mta-cli transform openrewrite
4.2. Updated CLI commands
List sources
$ mta-cli rules list-sources
List targets
$ mta-cli rules list-targets
List providers
$ mta-cli provider list
Test rulesets
$ mta-cli rules test <path_to_ruleset>Transform
$ mta-cli openrewrite