MTA Analysis

2 minute read

🚨 Deprecation Notice: 🚨
From Orchestrator release version 1.7, Workflow Types will be retired. All workflows will act as infrastructure workflows, and no workflow will act as an assesment workflow.
This workflow, being an assessment workflow, will be obsolete and irrelevant.

MTA - migration analysis workflow

Synopsis

This workflow is an assessment workflow type, that invokes an application analysis workflow using MTA and returns the move2kube workflow reference, to run next if the analysis is considered to be successful.

Users are encouraged to use this workflow as self-service alternative for interacting with the MTA UI. Instead of running a mass-migration of project from a managed place, the project stakeholders can use this (or automation) to regularly check the cloud-readiness compatibility of their code.

Workflow application configuration

Application properties can be initialized from environment variables before running the application:

Environment variable	Description	Mandatory
`BACKSTAGE_NOTIFICATIONS_URL`	The backstage server URL for notifications	✅
`NOTIFICATIONS_BEARER_TOKEN`	The authorization bearer token to use to send notifications	✅
`MTA_URL`	The MTA Hub server URL	✅

Inputs

repositoryUrl [mandatory] - the git repo url to examine
recipients [mandatory] - A list of recipients for the notification in the format of user:<namespace>/<username> or group:<namespace>/<groupname>, i.e. user:default/jsmith.

Output

On completion the workflow returns an options structure in the exit state of the workflow (also named variables in SonataFlow) linking to the move2kube workflow that will generate k8s manifests for container deployment.
When the workflow completes there should be a report link on the exit state of the workflow (also named variables in SonataFlow) Currently this is working with MTA version 6.2.x and in the future 7.x version the report link will be removed or will be made optional. Instead of an html report the workflow will use a machine friendly json file.

Dependencies

MTA version 6.2.x or Konveyor 0.2.x
- For OpenShift install MTA using the OperatorHub, search for MTA. Documentation is here
- For Kubernetes install Konveyor with olm
```
kubectl create -f https://operatorhub.io/install/konveyor-0.2/konveyor-operator.yaml
```

Runtime configuration

key	default	description
mta.url	http://mta-ui.openshift-mta.svc.cluster.local:8080	Endpoint (with protocol and port) for MTA
quarkus.rest-client.mta_json.url	${mta.url}/hub	MTA hub api
quarkus.rest-client.notifications.url	${BACKSTAGE_NOTIFICATIONS_URL:http://backstage-backstage.rhdh-operator/api/notifications/}	Backstage notification url
quarkus.rest-client.mta_json.auth.basicAuth.username	username	Username for the MTA api
quarkus.rest-client.mta_json.auth.basicAuth.password	password	Password for the MTA api