-
Story
-
Resolution: Unresolved
-
Major
-
None
-
None
-
Quality / Stability / Reliability
-
21
-
False
-
-
False
-
-
-
None
The feature is the Centralized Configuration Management for the MTA architecture (Hub, CLI, and IDE plugin). This enhancement aims to enable organizations to enforce standards across different MTA components by centralizing configuration management in the Hub.
The feature establishes the Hub as an optional source of truth for configuration, including Analysis Profiles, custom rules, and LLM/GenAI proxy configuration. This allows architects to define organization-wide configuration standards and automatically synchronize them across the developer tools (IDE and CLI).
Summary
This enhancement proposes enabling MTA to provide a Platform Engineering approach to Migration and Modernization{}, based on the following principles:
- Enable organizations to enforce standard practices and configurations to be easily followed by all developers involved in the migration initiative.
- Harmonize concepts and abstractions across all components.
- Enable connectivity between the local components (IDE Plugins, CLI) and the central Hub:
- Share application data across components:
Key Concepts to Document:
- Hub as Source of Truth: The Hub will be the centralized place to create, manage, and distribute configuration bundles, including Analysis Profiles.
- Analysis Profiles Abstraction: This feature brings the Analysis Profiles abstraction from the IDE plugin to the Hub, allowing architects to manage them organization-wide.
- Synchronization to Clients: The IDE and CLI components will include a login option to connect to the Hub, pull the configuration, and display the active profile.
Personas and Jobs-to-be-Done (JTBD) Statements
The following JTBD statements highlight the user's need, the new functionality, and the desired outcome.
1. System/Cloud Architect (The Enforcer/Planner)
This persona is responsible for setting and maintaining organizational standards and ensuring the migration project adheres to them.
| Role | Task (Motivation) | Goal (Expected Outcome) |
| As a System Architect, | I want to define and manage organization-wide Analysis Profiles and migration rules in the central Hub |
to enforce standard practices and configurations for application analysis, ensuring all teams use consistent, approved settings. |
| As a System Architect, | I want to configure the GenAI proxy and LLM settings once in the Hub |
to automatically remove the need for individual developers to configure LLMs locally in their plugins, streamlining setup and controlling access to AI services. |
2. Application Developer (The Implementer/User)
This persona is responsible for the actual application migration work and benefits from a streamlined setup process.
| Role | Task (Motivation) | Goal (Expected Outcome) |
| As an Application Developer, | I want to simply log into the Hub from my IDE or CLI |
to automatically pull down the correct configuration and Analysis Profiles for my application, making it simple to start work with a known good configuration. |
| As an Application Developer, | I want the IDE/CLI to use a Hub-managed profile associated with my application |
to trust that I am using the required, up-to-date configuration defined by my architects, avoiding errors from outdated or incorrect local settings. |
CLI Commands: Centralized Configuration Management
The Kantra CLI will introduce new subcommands to handle the connection and synchronization with the Konveyor Hub. This moves away from complex flags on single commands toward a clearer, more discoverable workflow for the end-user.
> [!NOTE]
>
> Check what these commands will be when moved downstream
1. Connecting to the Hub
The initial job for the developer is simply to get the local tool authorized and connected to the central source of truth.
| JTBD Statement | New Command | Description for Technical Writer |
| As an Application Developer, I want to authenticate my local CLI with the central Hub to gain access to the organization's standard Analysis Profiles and configurations. | kantra login | This new subcommand prompts the user for the Hub login information (credentials). It establishes a connection that allows the CLI to retrieve Hub-managed configuration bundles and profiles. This is foundational, similar to how kubectl login is used before other kubectl commands. |
2. Synchronizing and Using Profiles
Once connected, the developer's main job is to ensure they are using the correct, up-to-date configuration (Analysis Profiles) for their application. The Hub becomes the primary source of truth in this mode.
| JTBD Statement | New Command | Description for Technical Writer |
| As an Application Developer, I want to verify and synchronize the latest organization-wide Analysis Profile for my application so I can confidently run an analysis that adheres to the established migration standards. | kantra config sync (Proposed alternative to original analyze-sync) |
This command retrieves the associated Analysis Profiles from the Hub based on the application's remote URL. If the local on-disk profile is not in sync with the server-side configuration, the Hub-sourced profile will overwrite the local file. The core concept is a one-way sync from Hub to client . |
| As an Application Developer, I want to see a list of available Hub-managed Analysis Profiles for my application so I can select the correct one when multiple options exist. | kantra analyze --list-profiles <app> (Original) or a dedicated subcommand (Proposed) |
This lists the profiles associated with the application, typically those linked via an archetype-target platform taxonomy on the Hub. If the Hub returns multiple profiles, the user will need to choose which one to use. |
Configuration Precedence
The technical writer must clearly document the rules of configuration precedence to manage user expectations, especially regarding locking and local overrides.
The goal is to enforce hub-centric control.
| Precedence Level | Source of Configuration | Behavior |
| Highest | CLI/IDE Override Flags | Allows a user to temporarily override or unlock a Hub-managed setting. |
| Middle | Local Profile | The profile that is stored on the user's disk (e.g., in konveyor/profiles/). This is overridden by the Hub profile when sync is active. |
| Lowest | Hub-managed Profile | The central profile published by the Architect. This is marked as read-only upon synchronization to enforce the standard. |
> [!IMPORTANT]
> The documentation should emphasize that when the Hub mode is enabled, local configurations are ignored, as the Hub becomes the optional source of truth.
The Centralized Configuration Management feature is highly relevant to the Migration Toolkit for Applications (MTA) documentation, as it directly impacts how architects and developers use the MTA tools (Hub, CLI, IDE plugin).
The new documentation will focus on the Platform Engineering approach to migration, emphasizing organizational enforcement and streamlined user setup.
What This Documentation Would Include
The content should be organized around the core components affected by centralized configuration and framed by the Jobs-to-be-Done (JTBD) for the Architect (who sets policy) and the Developer (who uses the tools).
| Section | Target Persona | Key Content | JTBD Focus |
| Centralized Configuration Overview | Architect, Developer | Motivation, goals, and the new Hub as Source of Truth concept. Explanation of how this enables enforcing standard practices across the organization. | Understand the new configuration paradigm. |
| Managing Analysis Profiles (Hub UI) | System Architect | Detailed guide on creating and managing Analysis Profiles in the Hub UI, including linking them to rulesets and archetypes/target platforms. How to lock profiles to prevent local overrides. | Enable Architects to manage organization-wide configuration in the Hub. |
| Configuring LLM/GenAI Integration | System Architect | Steps to configure the GenAI proxy and LLM settings within the Hub. Explanation of how these settings are included in the configuration bundle and pushed to clients, removing the need for local developer configuration. | Control and standardize access to AI-powered refactoring. |
| Using the Konveyor CLI (Kantra) | Application Developer | Comprehensive documentation of the new login and sync workflow and new commands:kantra login: How to authenticate the CLI with the Hub. kantra config sync (or similar): How to synchronize Hub-managed configuration and overwrite local files.Configuration precedence rules (Hub > Local, etc.). | Streamline developer setup and ensure use of correct configuration. |
| Using the IDE Plugin | Application Developer | Steps for the developer to enable Hub mode in the IDE (e.g., VS Code or IntelliJ). How to handle profile selection when multiple Hub profiles are available for an application. Explanation of how local configs are ignored when Hub mode is active. | Easily adopt cloud-native technologies using validated migration paths. |
Where This Documentation Would Go
Based on the structure of the existing Migration Toolkit for Applications (MTA) documentation, the new content would primarily be integrated into the following sections:
1. New Section or Chapter: "Centralized Configuration and Governance"
Given the scope of this enhancement—affecting all three MTA components (Hub, CLI, IDE) and changing the organizational approach to configuration—it warrants its own top-level chapter. This chapter would introduce the Platform Engineering philosophy and the new capabilities.
2. Integration into Existing Component Chapters
Specific, practical instructions for the developer would be nested within the guides for each tool:
- Under "Configuring and managing the Migration Toolkit for Applications user interface":
-
- The architect's guide on creating, editing, and locking Analysis Profiles would be added here.
- Under "Using the MTA command-line interface to analyze applications":
- The new Under "Configuring and using the Visual Studio Code Extension for MTA" / "IntelliJ IDEA Plugin Guide":
- This integration strategy aligns with the JTBD concept by ensuring that users find the necessary configuration instructions right where they are performing their job in the tool of their choice.