[RFE] Allow the association of target platforms with Archetypes

[rromannissen]

What is the problem?

There is no way for an organization to enforce certain migration paths for applications associated with a certain archetype to land on specific target platforms. This allows migrators to explore migration paths that are not sanctioned by the organization, opening up the door for runtime/platforms and technology stacks that don't meet the corporate policy.

Why is this a problem?

After interviewing several large organizations, it has been revealed that modernization projects are perceived by them as an opportunity to further standardize the application landscape, narrowing down the number of allowed archetypes, technology stacks and runtime/platforms to a few supported options. For MTA to be useful on that approach at scale, there needs to be a way for organizations to model the supported runtimes/platforms and technology stacks and associate them with archetypes, and from there, streamline and simplify the analysis process for migrators.

Proposed solution

• The concept of Target Platform will be introduced to model a potential runtime/platform for applications that are associated to a given archetype.
• For each Target Platform associated to a given archetype, users should be able to associate one or many migration paths.
  • Target Platforms could have different sets of migration paths for different archetypes. For example, the "Kubernetes" Target Platform could include the OpenJDK 21, EAP 8 and Containerization migration paths for the "EAP 6" archetype, and then include the OpenJDK 21 and Containerization migration targets for the "Spring Boot" archetype.

• These relationships could be used to enforce certain migration motions for migrators on the analysis wizard or external systems like the CLI, IDE plugins and potential future integrations with Backstage.

Open Questions

• Should this relationship be managed in the Migration or the Administration perspective?

[konveyor-ci-bot]

This issue is currently awaiting triage.
If contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members.

[sjd78]

Some of my initial thoughts:

• Migration Paths seem like another way to describe a migration target, which really is a ruleset target label. For example, the "Application server migration to" target card with "JBoss EAP 8" selected ultimately enables the label konveyor.io/target=eap8 on an analysis.

• Target Platform looks like a collection of target labels. Following the example in the diagram, Kubernetes could be a set of labels konveyor.io/target=cloud-readiness, konveyor.io/target=openjdk21, and konveyor.io/target=eap8.

• Archetypes would just need to be extended to support a collection of Target Platforms.

• If an Archetype has a set of Target Platforms, the Analysis Wizard would just union the set of Target Platforms from all selected Applications, and then either...

  • Preselect the target cards based on the union of target platform labels, or
  • Allow selection of targets by selecting the target platforms (2 sets of selections would be available -- Target Platforms and Target Cards)
  • Question: If Target Platforms are in effect via an Application's Archetype, can the target cards still be selected directly?

[rromannissen]

@sjd78 I think you are totally right in your assumptions. About your question, I think that could be a configuration thing, allowing the admin to restrict whether migrators can still make choices outside the indirect relationship between archetypes and migration paths or not. Example: If an application belongs to Archetype EAP 6 associated with Kubernetes and Traditional Standalone, allowing migrators to still manually select "Quarkus" or not would depend on some configuration parameter.