kyma_poc

kyma_poc

Kyma (en grec pour Wave, https://www.howtopronounce.com/kyma) est une démonstration de preuve de concept utilisant l'IA générative à l'intérieur de Konveyor.io pour aider aux efforts de modernisation du code.

Diapositives : Konveyor KymaML : migration du code GenAI

Aperçu

• Kyma se concentre sur l'exploitation des données que Konveyor collecte déjà via Migration Waves et sur sa vision du portefeuille d'applications d'une organisation.
• Kyma examinera le rapport d'analyse d'une application donnée et générera des correctifs potentiels pour chaque incident.
  • Cela se fait en examinant des incidents similaires qui ont été résolus dans d'autres applications, en récupérant la différence de code qui a corrigé cet incident et en travaillant avec un LLM pour exploiter la façon dont l'organisation a résolu le problème dans le passé pour cette application et cet incident spécifiques.
    • Pour le POC, cela impliquera d'examiner les applications qui ont à la fois des solutions Javaee et Quarkus, nous simulerons à quoi ressemblerait l'expérience dans Konveyor où nous avons accès à un portefeuille d'applications plus large et pouvons trouver des applications similaires qui ont déjà été migrées et les utiliser comme exemples.
• L'approche s'appuie sur une ingénierie rapide avec des exemples Few Shots et une série d'agents pour travailler avec le LLM afin d'améliorer le correctif généré.
  • Remarque : La formation et la mise au point du modèle ne sont pas requises dans cette phase. Nous prévoyons d'affiner le projet en conjonction avec Open Data Hub à l'avenir, en tirant parti des modèles de fondation open source de huggingface.co, mais cela est hors de portée pour cette phase actuelle.
• Nous supposons que Kyma travaillera avec différents modèles, nous nous concentrons sur l'ingénierie des outils/invites et prévoyons de traiter les coordonnées du modèle comme une entité interchangeable. Cela nous permet d’expérimenter des modèles évolutifs.

Quels sont nos critères de réussite de la preuve de concept

• Nous voulons évaluer quel niveau de qualité nous pouvons obtenir grâce à une ingénierie rapide, c'est-à-dire sans réglage fin.
  • Les phases futures pourront tirer parti d'un réglage fin, mais cette phase concerne une approche plus simple de création d'outils pour collecter des données utiles dans Konveyor et utiliser l'ingénierie d'invite pour aider les migrants avec les modifications de code.
• Ce POC est destiné à être un petit projet Python permettant de travailler avec quelques exemples d'applications et de rapports d'analyse afin d'évaluer l'utilité des correctifs générés dans le domaine de la modernisation des applications Java EE vers Quarkus.
• Le succès pour nous est de pouvoir générer des correctifs qui font gagner du temps au Migrator travaillant sur la modernisation d'une application.
  • Nous supposons que les correctifs ne seront pas toujours fonctionnels à 100 % et impliqueront une certaine intervention de l’utilisateur. Le succès dépendra du degré d’intervention nécessaire et de la capacité des correctifs à apporter suffisamment d’aide pour gagner du temps.

Installation

1. python -m venv env
2. source env/bin/activate
3. pip install -r ./requirements.txt
4. Installez podman pour pouvoir exécuter Kantra pour l'analyse de code statique

En cours d'exécution

Exécuter une analyse d'un exemple d'application (exemple pour MacOS)

1. cd data
2. ./fetch.sh # cela va cloner quelques exemples d'applications de code source
3. ./darwin_restart_podman_machine.sh # configure la VM podman sur MacOS afin qu'elle monte le système de fichiers hôte dans la VM
4. ./darwin_get_latest_kantra_cli.sh # récupère 'kantra' notre outil d'analyse
5. ./analyzer_coolstuff.sh # Analyse le répertoire 'coolstuff-javaee' et écrit une sortie d'analyse dans example_reports/coolstuff-javaee/output.yaml
   • Suivez cet exemple pour analyser d’autres exemples d’applications

Générer une version Markdown d'un rapport d'analyse donné

• Cela prendra la sortie YAML et la convertira en Markdown pour une vue plus facile

1. Démarrer à la racine du projet et exécuter
   • ./kyma.py report data/example_reports/coolstuff-javaee/output.yaml example_output/coolstuff-quarkus

     • Cela suppose qu'un rapport d'analyse Kantra en YAML existe dans data/example_reports/coolstuff-javaee/output.yaml

     • Exemple d'exécution de sortie :

         $ time ./kyma.py report data/example_reports/coolstuff-javaee/output.yaml example_output/coolstuff-quarkus
         We have results from 4 RuleSet(s) in data/example_reports/coolstuff-javaee/output.yaml
       
         Writing eap7/websphere to example_output/coolstuff-quarkus/eap7_websphere.md
         Writing eap8/eap7 to example_output/coolstuff-quarkus/eap8_eap7.md
         Writing openshift to example_output/coolstuff-quarkus/openshift.md
         Writing quarkus/springboot to example_output/coolstuff-quarkus/quarkus_springboot.md
         ./kyma.py report data/example_reports/coolstuff-javaee/output.yaml   1.28s user 2.12s system 337% cpu 1.007 total
       

     • Des exemples de sorties peuvent être consultés depuis github pour data/example_reports/coolstuff-javaee/output.yaml

       • exemple_output/coolstuff-quarkus/eap7_websphere.md
       • exemple_output/coolstuff-quarkus/eap8_eap7.md
       • exemple_output/coolstuff-quarkus/openshift.md
       • exemple_output/coolstuff-quarkus/quarkus_springboot.md

Générer le résultat de l'interaction LLM

1. export OPENAI_API_KEY="mysecretkey"
   • Voir https://platform.openai.com/api-keys pour créer une clé API
2. ./generate_coolstuff.sh
   • Voir generate_coolstuff.sh comme exemple de la façon d'invoquer
3. Consultez les résultats pour ce qui précède sur example_output/coolstuff-quarkus
   • 2 types de fichiers sont produits en sortie pour le premier incident de chaque violation (nous travaillons uniquement sur le premier incident pour le moment)
     • '*_full_run.md' Un fichier de démarque qui montre l'invite qui a été envoyée au LLM et le résultat complet
     • ".diff" - Un diff produit pour le premier incident de chaque violation
   • Notez que nous répartissons les résultats en fonction du modèle à rechercher :
     • exemple_output/coolstuff-quarkus/gpt-3.5-turbo-16k
     • exemple_output/coolstuff-quarkus/gpt-4-1106-preview
   • Exemple de problème spécifique et de résultat :
     • example_output/coolstuff-quarkus/gpt-4-1106-preview/quarkus_springboot_cdi-to-quarkus-00050_2_full_run.md

Remarques

• Idée des temps d'exécution lorsque nous traitons coolstuff-store pour :
  • -t "quarkus" -t "jakarta-ee" -t "jakarta-ee8+" -t "jakarta-ee9+" -t "cloud-readiness"
    • 'gpt-3.5-turbo-16k'
      • time ./generate_coolstuff.sh 5.12s user 3.46s system 1% cpu 11:02.25 total
    • 'gpt-4-1106-aperçu'
      • ./generate_coolstuff.sh 4.86s user 3.73s system 0% cpu 15:52.24 total