This document is a roadmap for Konveyor AI (Kai). The roadmap is organized by themes of functionality, each focusing on a specific aspect of the project's development. Roadmap Ouline: Guiding Principles Themes Milestones Future Areas to Consider What is the purpose of Konveyor AI?Kai intends to improve the economics of re-platforming and refactoring applications to Kubernetes and cloud-native technologies via use of Generative AI leveraging data in Konveyor.

analyzer-lsp is a rules engine that uses language providers to enable static code analysis of different languages. image The two important pieces above are: Rules Engine: The engine is the core component responsible for parsing rules, invoking providers to run them, and generating output. Providers: The providers are responsible for accepting queries in the rules as input, converting them into LSP queries for the language servers and sending the results back to the engine. While most providers use LSP based language servers for analysis, it's not a requirement. The engine communicates with a provider over gRPC and mainly invokes three routines:

Discontinued = Permanently removed Not supported = Not possible right now, may or may not be added later. Rules Rules can only be written in YAML. Rules written in groovy and java are discontinued. Some of the previous groovy / java rules have been converted to YAML rules wherever possible. An important change in the rules engine is that you can no longer query anything other than tags stored in engine's internal data structures. As a result, all features enabled via <graph-query> element in the rule are discontinued.https://access.redhat.com/documentation/en-us/migration_toolkit_for_applications/6.2/html/rules_development_guide/creating_xml_rules#graph-query-syntax_rules-development-guide <javaclass> child elements <annotation-list>, <annotation-type> and <annotation-literal> are not supported in the current version.

Konveyor is a CNCF project focused on accelerating application modernization to cloud native technologies in a safe and predictable manner at scaleRelated documents for more background on Konveyor:Konveyor Project Charter Vision for Konveyor's Unified Experience Konveyor Application Modernization and Migration Guide Where to file new RFEs? -> https://github.com/konveyor/enhancements/issues/new Read our enhancements to learn more about design choices and how features are being implemented Near-term: 2023 Q3-Q4 Theme: Establish Steps 1->3 of Unified Experience: 'Surface Information -> Make Decisions -> Plan Work'Multi-language analysis supportA new analysis engine, analyzer-lsp, is being developed to leverage the Language Server Protocol to make additional languages easier to integrate.enhancement: Konveyor Analysis: Multi-language analyzer leveraging Language Server Protocol (LSP)

Prior Submission Summer 2023 Konveyor Extend use-case of detecting deprecated Kubernetes API usage Description: Konveyor provides a unified experience of tools to help organizations modernize their applications at scale to Kubernetes and cloud-native technologies. We are looking for help on extending a use-case of detecting usage of deprecated and removed Kubernetes APIs in applications. This work will involve determining what API resources have been deprecated or removed in each version of Kubernetes and then building Analyzer LSP Rules to be contributed to our Rulesets repository, curation or development of sample applications in Golang, Java, and YAML to aid test scenarios, and documentation to help show a guided walkthrough of this capability. You can see the beginning of this use-case being addressed with this sample rule in this demo of analyzer-lsp. The development environment is based on Golang and Kubernetes. A minikube instance will work well for local development on Linux or Mac systems. Expected Outcome:Rules contributed to konveyor/rulesets to detect both deprecated and removed usage of Kubernetes APIs. Coverage for YAML, Golang, and Java source code, addition of this scenario into the project's automated test suite, and documentation of a guided scenario showing usage of these rules via a curated set of application source code examples. Recommended Skills: Go

This document describes steps needed to run the Dynamic Reports demo in your local environments. Steps include: Install Konveyor Tweak some of the components to get the latest changes Install the new LSP analyzer addon Set up a sample application for analysis Installation Setting up minikube Follow your usual minikube installation steps and make sure you enable Nginx Ingress and OLM plugins. I used the script published in Konveyor Operator repository here to install minikube with required dependencies.

We are thrilled to announce the release of Konveyor 0.2.0! This release supports various features, like migration waves, integration with Jira, and other valuable minor updates. Key Highlights of Konveyor 0.2.0: Migration waves Jira Integration Minor improvements :sparkles: Migration Waves: We are excited to introduce a significant addition to the Konveyor project, aimed at providing enhanced value throughout the migration process. We recognized the need to address the planning aspect required to scale the migration process across entire application portfolios. When dealing with a large-scale portfolio containing hundreds or even thousands of applications, it becomes impractical to execute the migration process in one go. To tackle this challenge, we have introduced the ability for Konveyor to define migration waves, allowing for an iterative and manageable approach. By breaking down the portfolio into waves, we enable a more sophisticated process that can automate the calculation of these waves based on various criteria. This feature empowers users to scale adoption efforts effectively, ensuring a seamless and efficient migration experience.

Recurrent: [ ] Release announcement [ ] Quarterly updates Ideas: [ ] 0.2.0 blog post highlighting features [ ] Sneak peak kinda post efore kubecon [ ] Interview with a contributor and/or an adopter

Author: Savitha Raghunathan Konveyor aims to surface insights on applications at scale to empower enterprise users to make better-informed decisions related to modernization activities. When it comes to migrating applications to Kubernetes (K8s), it's important to note that some applications can be ported without any major issues. However, there are certain edge cases where applications may encounter difficulties during the migration process. One such edge case we will focus on in this tutorial involves Hazelcast. Hazelcast is an open-source in-memory data grid that provides distributed caching and data synchronization capabilities. In this tutorial, we will use Hazelcast as the session backing store. During the migration of an application utilizing Hazelcast, some issues arise due to the distributed nature of Hazelcast and the dynamic nature of a Kubernetes environment. In this specific case, network connectivity and discovery issues impact the functionality of the petclinic application. To tackle this challenge, the tutorial will not only guide you on how to identify and translate specific edge case issues into custom rules but also emphasize the long-term benefits of sharing this knowledge within the organization. By investing time and effort in creating custom rules for this particular application, you are laying the groundwork for future migrations and modernizations throughout the app portfolio. Once we have integrated these custom rules as targets with Konveyor, we will gain valuable insights that can be applied to other applications in the portfolio. This knowledge-sharing mechanism allows others in the organization to quickly recognize similar issues and provides a clear path for resolving them. While creating custom rules may require additional effort initially, the resulting knowledge base will serve as a valuable resource for scaling these efforts across teams. It's not just about solving the problem for one application; it's about empowering others in the organization to handle future modernizations and migrations more efficiently. By sharing the insights gained from Konveyor and the custom rules, you contribute to the overall growth of knowledge and shorten the learning curve for future projects. Goals: This example will explore the reasons behind the failed attempt to lift and shift the petclinic app to Kubernetes.

The official OpenShift OADP Data Mover documentation can be found here We maintain an up to date FAQ page here Background Information: OADP Data Mover 1.2 leverages some of the recently added features of Ceph to be performant in large scale environments, one being the shallow copy method, which is available > OCP 4.11. This feature requires use of the Data Mover 1.2 feature for volumeOptions so that other storageClasses and accessModes can be used other than what is found on the source PVC.

This is the first revision of Rules for LSP analyzers in Konveyor. Rule A Rule consists of conditions, actions and metadata. It instructs analyzer to take specified actions when given conditions match. Metadata fields of a rule are: # id must be unique among all provided rules ruleId: "unique_id" # violations have pre-defined categories

Goals In this example, you will learn the insights on what changes are required to containerize a Java application running on tomcat server. This example uses Tackle operator to perform analysis on the application source code, the results of which produces insights needed to containerize the app. Prerequisites Minikube Podman Tackle Operator Tackle Operator Installation To install tackle operator in your minikube cluster, follow along these set of instructions