🔌 Plugin: Migration Toolkit for Applications (MTA) / Konveyor #516
Comments
|
The parodos plugin mentioned above is meant to run workflows. One of the main workflows worked on is to perform an MTA analysis, but it has no integration with backstage components so nothing is surfaced. Are you looking into invoking an analysis or this is just a view only plugin? |
|
Hey Roy,
the main use case is to surface MTA data (including assessment and analysis
reports) in context of the component in Backstage.
Triggering an analysis _might_ be an additional UC but that's not in scope
right now.
Cheers,
Markus
…---- Sent from a mobile device - typos and funny autocorrect results are my
special gift to you ----
On Mon, 24 Jul 2023, 14:56 Roy Golan, ***@***.***> wrote:
The parodos plugin mentioned above is meant to run workflows. One of the
main workflows worked on is the perform an MTA analysis, but it has no
integration with backstage components so nothing is surfaced.
Are you looking into invoking an analysis or this is just a view only
plugin?
—
Reply to this email directly, view it on GitHub
<#516 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AH562KJDLQ37A7VKHUL37VTXRZWGLANCNFSM6AAAAAA2E242DQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
@markusjnagel, how do developers use this information? Is this information the need all the time or just once? |
|
Hey Brad 👋,
let me reply in UC speak:
1) As a developer, I want to see the issues that the MTA analysis generated
for a component, so that I can start working on those without the need to
login to MTA.
2) As an Architect, I want to see the assessment report and associated
risks for a given component so that I can help my team prioritise.
These are the two primary/MVP use cases I see but since a modernisation
isn't happening overnight, there could be:
3) As a developer I want to trigger another analysis for a given component
in context of the component page, so that I can see an updated list of MTA
issues associated with my component.
So, this third UC would benefit from what the Parodos team has already
built, although it is not a workflow but just a one-off trigger by a
developer.
Generally, the idea is not to rebuild the MTA UI or functionality but just
to surface key info from MTA in context of a Backstage component to support
developers with their modernisation tasks.
For more detailed info or interaction, a link to MTA from the component
page would be helpful.
Cheers,
Markus
(BTW - sorry I'm only replying via email, hope it renders correct in
GitHub. I'm on vacation without laptop - only cellphone and limited
bandwidth to make matters worse)
…---- Sent from a mobile device - typos and funny autocorrect results are my
special gift to you ----
On Mon, 24 Jul 2023, 18:58 Brad Bazemore, ***@***.***> wrote:
@markusjnagel <https://github.com/markusjnagel>, how do developers use
this information? Is this information the need all the time or just once?
—
Reply to this email directly, view it on GitHub
<#516 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AH562KLLEPZTLSVBVE3FFA3XR2STNANCNFSM6AAAAAA2E242DQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
This issue has been closed due to the fact that the Janus community is being sunset. For future plugin issues, please use https://github.com/backstage/community-plugins/issues For future showcase issues, please use https://issues.redhat.com/browse/RHIDP For more information on the sunset, see: https://janus-idp.io/blog/2024/07/05/future-of-janus-community |
🔖 Summary
To support developers working on components that need to be migrated or modernised, it would be beneficial to surface related information on the component level (speak: the Backstage Component Page).
As opposed to creating new components (via templates / Golden Paths), this use case is primarily focused on existing components / applications.
However, the goal would not be to replicate the full MTA UI in Backstage, but to give developers just enough information about the component they are working with.
If the catalog-info.yaml of any given (imported) component contains the right tags/annotations, the component overview could surface high-level migration information from MTA:
In a component plugin detail page, more information, such as report highlights, issue categories, as well as links to MTA , etc could be shown (this screenshot left empty on purpose)
Also, some interaction with MTA (e.g. open an existing analysis or assessment report) would be beneficial.
(see details below)
🌐 Project website (if applicable)
https://www.konveyor.io/
https://github.com/konveyor
https://github.com/konveyor/tackle2-hub/blob/main/docs/swagger.json
https://developers.redhat.com/products/mta/overview
✌️ Context
This proposed plugin is trying to surface relevant migration-related information in the component context, as a developer is working with it.
Therefore, a plugin (and relevant contextual information) should only be shown if an imported component has a relevant "migration" entry in its catalog-info.yaml
There already is the Parodos team working on a plugin
#178
https://github.com/parodos-dev/backstage-parodos/tree/main/plugins/parodos
but this is (as far as I know) targeted on creating an "Application" entry in the MTA Application Inventory and triggering the analysis - which is great by the way, but it doesn't link back to the component, as it lives in its own sidebar entry.
So, these two follow different use cases (however, might be joined/merged later).
There is also this issue
#505
but the context here is the MTA DevSpaces plugin - which could be an item for the backlog to add to the component details page.
👀 Have you spent some time to check if this plugin request has been raised before?
🏢 Have you read the Code of Conduct?
Are you willing to submit PR?
Yes I am willing to submit a PR!
The text was updated successfully, but these errors were encountered: