Skip to content

[WIP] New Installing MTA UI and CLI title #173

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

mpershina
Copy link
Collaborator

@mpershina mpershina commented Aug 1, 2025

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

did you mean to include this file?



+
You can use these add-on to perform the following tasks:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
You can use these add-on to perform the following tasks:
You can use these add-ons to perform the following tasks:

use plural and singular nouns correctly



+
You can use these add-on to perform the following tasks:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
You can use these add-on to perform the following tasks:
You can use this add-on to perform the following tasks:

[id="roles-personas-users-permissions_{context}"]
= Roles, personas, users, and permissions

The {ProductFullName} uses three roles, each corresponds to a persona. The roles are already defined in your RHBK instance. You do not need to create them. If you are an {ProductShortName} administrator, you can create users in your RHBK and assign each user one or more roles, one role per persona. Although a user can have more than one role, each role corresponds to a specific persona:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The {ProductFullName} uses three roles, each corresponds to a persona. The roles are already defined in your RHBK instance. You do not need to create them. If you are an {ProductShortName} administrator, you can create users in your RHBK and assign each user one or more roles, one role per persona. Although a user can have more than one role, each role corresponds to a specific persona:
The {ProductFullName} uses three roles, each corresponds to a persona. The roles are already defined in your RHBK instance. You do not need to create them. If you are an {ProductShortName} administrator, you can create users in your RHBK and assign each user one or more roles, one role per persona. Although a user can have more than one role, each role corresponds to a specific persona:


The {ProductFullName} uses three roles, each corresponds to a persona. The roles are already defined in your RHBK instance. You do not need to create them. If you are an {ProductShortName} administrator, you can create users in your RHBK and assign each user one or more roles, one role per persona. Although a user can have more than one role, each role corresponds to a specific persona:

* The `tackle-admin` role corresponds to the Administrator persona. The administrator has all the permissions that architects and migrators have, along with the ability to create some application-wide configuration parameters that other users can consume, but cannot change or view, for example, Git credentials or Maven `settings.xml` files.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* The `tackle-admin` role corresponds to the Administrator persona. The administrator has all the permissions that architects and migrators have, along with the ability to create some application-wide configuration parameters that other users can consume, but cannot change or view, for example, Git credentials or Maven `settings.xml` files.
* The `tackle-admin` role corresponds to the Administrator persona. The administrator has all the permissions that architects and migrators have, along with the ability to create some application-wide configuration parameters that other users can consume but cannot change or view, for example, Git credentials or Maven `settings.xml` files.


* The `tackle-admin` role corresponds to the Administrator persona. The administrator has all the permissions that architects and migrators have, along with the ability to create some application-wide configuration parameters that other users can consume, but cannot change or view, for example, Git credentials or Maven `settings.xml` files.

* The `tackle-architect` role corresponds to the Architect persona. An architect is a technical lead for the migration project who can run assessments and can create and modify applications and information related to them. The architect cannot modify or delete sensitive information, but can consume it. For example, the architect can associate an existing credential to the repository of a specific application.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* The `tackle-architect` role corresponds to the Architect persona. An architect is a technical lead for the migration project who can run assessments and can create and modify applications and information related to them. The architect cannot modify or delete sensitive information, but can consume it. For example, the architect can associate an existing credential to the repository of a specific application.
* The `tackle-architect` role corresponds to the Architect persona. An architect is a technical lead for the migration project who can run assessments and can create and modify applications and information related to them. The architect cannot modify or delete sensitive information but can consume it. For example, the architect can associate an existing credential to the repository of a specific application.


* The `tackle-architect` role corresponds to the Architect persona. An architect is a technical lead for the migration project who can run assessments and can create and modify applications and information related to them. The architect cannot modify or delete sensitive information, but can consume it. For example, the architect can associate an existing credential to the repository of a specific application.

* The `tackle-migrator` role corresponds to the Migrator persona. A migrator is a user who can analyze applications, but not create, modify, or delete them.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* The `tackle-migrator` role corresponds to the Migrator persona. A migrator is a user who can analyze applications, but not create, modify, or delete them.
* The `tackle-migrator` role corresponds to the Migrator persona. A migrator is a user who can analyze applications but not create, modify, or delete them.


* The `tackle-migrator` role corresponds to the Migrator persona. A migrator is a user who can analyze applications, but not create, modify, or delete them.

{ProductShortName} has two views, *Administration* and *Migration*. Only administrators can access the *Administration* view. Architects and migrators have no access to Administration view, they cannot even see it. Administrators can perform all actions supported by *Migration* view. Architects and migrators can see all elements of *Migration* view, but their ability to perform actions in *Migration* view depends on the permissions granted to their role.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
{ProductShortName} has two views, *Administration* and *Migration*. Only administrators can access the *Administration* view. Architects and migrators have no access to Administration view, they cannot even see it. Administrators can perform all actions supported by *Migration* view. Architects and migrators can see all elements of *Migration* view, but their ability to perform actions in *Migration* view depends on the permissions granted to their role.
{ProductShortName} has two views, *Administration* and *Migration*. Only administrators can access the *Administration* view. Architects and migrators have no access to Administration view, they cannot even see it. Administrators can perform all actions supported by *Migration* view. Architects and migrators can see all elements of *Migration* view but their ability to perform actions in *Migration* view depends on the permissions granted to their role.

[id="creating-mta-instance_{context}"]
= Creating a MTA instance

You can use the {ProductFullName} user interface (UI) to assess and analyze your applications to get insights about the adoption process, at both the portfolio and application levels as you inventory, assess, analyze, and manage applications for faster migration to Red Hat OpenShift.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
You can use the {ProductFullName} user interface (UI) to assess and analyze your applications to get insights about the adoption process, at both the portfolio and application levels as you inventory, assess, analyze, and manage applications for faster migration to Red Hat OpenShift.
You can use the {ProductFullName} user interface (UI) to assess and analyze your applications to get insights about the adoption process at both the portfolio and application levels as you inventory, assess, analyze, and manage applications for faster migration to Red Hat OpenShift.

anarnold97

This comment was marked as outdated.

Copy link
Collaborator

@anarnold97 anarnold97 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some small nits but otherwise LGTM

@anarnold97 anarnold97 requested a review from ibragins August 13, 2025 13:51
Copy link
Collaborator

@anarnold97 anarnold97 Aug 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not correct

[id="installing-downloadable-cli-zip_{context}"]
== Installing the {CLINameTitle} `.zip` file

.Procedure

. Navigate to the link:{DevDownloadPageURL}[{ProductShortName} Download page] and download the OS-specific CLI file or the `src` file:
+
* {ProductShortNameLower}-{ProductVersion}-cli-linux-amd64.zip
* {ProductShortNameLower}-{ProductVersion}-cli-linux-arm64.zip
* {ProductShortNameLower}-{ProductVersion}-cli-darwin-amd64.zip
* {ProductShortNameLower}-{ProductVersion}-cli-darwin-arm64.zip
* {ProductShortNameLower}-{ProductVersion}-cli-windows-amd64.zip
* {ProductShortNameLower}-{ProductVersion}-cli-windows-arm64.zip
* {ProductShortNameLower}-{ProductVersion}-cli-src.zip

. Extract the `.zip` file to the `.kantra` directory inside your `$HOME` directory. The `.zip` file extracts the *mta-cli* binary, along with other required directories and files.

Also, please note Igor's comments on this PR - https://github.com/migtools/mta-documentation/pull/178/files#r2273545164

FYI - @ibragins

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants