 All right. Thank you, everybody, for attending and joining the conveyor community meetup today. Today we have a great topic of, you know, migrating applications to Kubernetes, modernizing them with the migration toolkit for applications. My name is James Lobaki. We have a great crew. I'm Marcus Noggle, Miguel Perez Collinio, Phil Katnatch and Marco Ritzi here to present on the topic and do a demonstration. The call is being recorded and so we will post the recording just like we do every time on there. So, Miguel, do you want to hit the next slide real quick? So just to let you guys know, there's a conveyor community meetup. You can go to conveyor.io if you want to see all the meetups. I would encourage you also to click on the forum button there and click Join Group. Right now we are sending invites to several mailing lists and kind of finding people that would be interested in participating in this community. It's a completely upstream community. The goal is to begin catalyzing a community that we bring practitioners together, dissadmins, developers and, you know, different engineers that are working on solving these problems of how you break down monoliths, adopt containers and embrace Kubernetes. So I'd encourage you to join that mailing list as we will slowly start only putting invites over to that mailing list. At the end of the session, we'll also present, we'll send a survey out like we always do to get your feedback, which we do take and share as well. And with that, I will invite you to enjoy the talk and turn it over to Marcus Noggle. Hey, good morning, good evening, good afternoon, wherever you are. Just a few words about me. I'm with Red Hat Consulting. Being your architect of my primary focus is, as you can see on the screen, migration and modernization. And I'll try to stick to my five minutes. So Miguel, if you could advance to the next one, please. So just a few words about how we as Red Hat Consulting typically tackle application migration, application migration projects. So typically, it all starts at Red Hat with a discovery session where we level set, where we level set where the customer wants to go, where you as a customer or you as a developer need to go. What your priorities are, why you're moving to Kubernetes and OpenShift as such and what your portfolio looks like. Now, in the actual project, we start with what we call Navigate, which is a prescriptive set of workshops that help identify gaps and the technology landscape that we're dealing with, like CIZD processes, etc. And then we come to the core point here, the application assessment, which I'll talk about in the next slide. Basically assessing what's the portfolio that we're talking about in terms of applications. When we have done that, or it can also be in parallel, after the first few applications that depends on the project setup, I'll leave all the nitty-gritty details out here. We can, if necessary, prove the technology. Let's just say you have, you're coming from, let's just pick, you come from WebLogic and you're using some proprietary methods and now you're looking at running on Wildfly, for example, and you have some libraries that need to be replaced with open source libraries and then you can prove, okay, this is a technical proof point, this is working. Then you move these, you move a few pilot applications to a production ready minimum viable product. So to prove the point, okay, this whole approach as such is working. You will learn a couple of things in these first steps and you will document all these in an onboarding process. So this is not strictly waterfall, it's just a little bit hard to present in a meaningful manner here. The onboarding process will be built from what you're learning in the application assessment, obviously from the first steps in your navigate. And so this will form a repeatable onboarding process for new applications for basically for your backlog. And then in the expand phase, what we call a factory approach typically will spread out, pan out into multiple parallel projects. As you see fit alone or with your partner, typically what we do is in the first part, we're in the leading role together with the customer. And in the later parts, we more and more phase over to the customer in the leading role where we just support the endeavor here. So if you go to the next one, what we're always asked, okay, so where do I start? I have such a big application portfolio, hundreds of applications, so what do I do? So, well, first of all, you might have business reasons to select applications. Those could be as simple as this is an important application. It could be things like you're coming, one of your components comes to end of life, end of support. Or it could be there's an upcoming renewal and I want to move to a new platform to avoid renewal costs, things like that. So typically business driven. The next step is the operational or also technical filter. We have a tool for that that's called Pathfinder. That is not in scope of this discussion, but it's basically a questionnaire based tool that helps us identify things like is the team ready? Do we have actually, do we have a team supporting the application? Let's just say your traditional company heavily siloed and then probably applications have been developed, have been handed over to operations. And after that, nothing has happened to the actual application development. The application development has basically stopped and the application has just been transferred to the operations team. So is there a team supporting the application? Other suitability factors like runtime behavior, is there a specific startup behavior that the application requires, which is obviously not ideal on Kubernetes? So you can start from there up to shortlisting because in every assessment, there's always the option that the assessment says, okay, this is not a good candidate. So then you would have to deal. There's other options like, for example, open shift virtualization. There could be an option leaving it in a VM or there's other options. But when it comes to moving applications onto Kubernetes, there might always be the not applicable or not advisable outcome of an assessment. So having that prioritized backlog, we can start from here with a certain risk or we can, as we typically do, what we recommend, go one level deeper and do the analysis with the migration toolkit for applications that will help us identify technical risks on a code level. And with that backlog, with that refined migration plan, you would then go into your application migration. That is actually a cycle because you will learn with the help of the migration toolkit, you will identify patterns. So what's very important also in terms of project is that you need to identify and document everything that you learn in a shared knowledge base, because let's say you have an application archetype, you're using this type of framework, the next time your next application from a totally different department is migrated. They can say, okay, if I encountered this topic then here, this is what we'll do. And this is also one thing that the migration toolkit helps you with the extensibility of rules. Okay, so a few words from the consulting side. Next one. Thank you, Marcus. Yeah. Did you want to add anything else? No, no, unless there's questions, we'll answer questions later in the Q&A, but yeah, feel free. Yeah, I really appreciate you joining us. I mean, I know that you've been migrating applications for quite a long time, many kinds of applications in many customers all around Europe and probably in other parts of the world. And it's good to hear how this is done, how do you start by selecting the applications and how do you filter them to create a list of a backlog of what are we going to do, what is the lowest risk, and what are the stakeholders that need to be together to be able to do a successful modernization of applications, especially in large companies. So now getting to the tool, you know, you have seen that there are several phases. One of them is the assessment phase where you review the applications that you probably have in your portfolio in your company and say, okay, what am I doing with these applications? How do I review them? And then you can establish, okay, these are the ones I would like to start migrating with. Sometimes you're not in a company, you're just having some applications that you have been managing yourself or for fun. And you want to review them also and think, okay, how can I modernize this? How can I bring these applications that I built some years ago and I want to bring it into Kubernetes. And this is where the migration toolkit for applications can help. So there are some cases that we're covering. Migrating, for example, to OpenJDK, if you're using Oracle JDK, finding those classes that are proprietary that you're using and maybe you should move away from them so you don't have to pay to Oracle in case you want to use JDK. Looking for, I don't know, modernized Tomcat or Springboard-based applications. If you are using, for example, community observers or libraries and you want to move them to support it because you want to take them into production, we are also there to cover you. And also Apache Camel, we have rules to migrate from Apache Camel 2 to Camel 3. Camel 3 has a lot of features that are specific to Kubernetes and to containers. And for many people who are using integration patterns with Apache Camel 2, moving to Camel 3 is such a huge step forward that they probably are very interested in doing so. And the migration toolkit for applications can help you there. Also, we have rules based on the 12-factor-app definition for containerization. So if you want to containerize your application and you're using something like, I don't know, shared session, and this shared session is done in a way that is not suitable for containers, we'll reach it out and we'll help you find what are the issues that were there that you probably want to fix before moving your application into a container. And also break down monoliths and understand with agile integration. So what is the migration toolkit for application? So first things first, this is fully open source. There's the windup project that is becoming part of Conveyor. And this project has all the code there for you to use it, to review it, to study it, to change it, modify it on whatever you want. So this migration toolkit is available for you in this URL, red.hts.mth. You can download it there for free. It's the developer portal of Red Hat and you just could get in there, download it and check it yourself. And we provide it in four flavors to say so. One of them is the command line interface for the people who want to do specific things when analyzing an application. Like, for example, automating it or using it in your laptop or in a server or embed it into weird pipelines that you have for your CI CD environment. We also have the web console, which is the easiest one to use. It has a nice interface that you can access and upload your binaries or tell it where your source code is. And then it will analyze it for you and it will provide your reports in HTML so you could go and review them. There are also IDE plugins for your Visual Studio code on your Eclipse or Eclipse J, which also have a version from Red Hat got ready workspaces and got ready studio. That is a curated version of the open source projects. And then a plugin for Maven just in case you want to do the analysis at the build time. So once you do the analysis, what does it do? Well, it reviews the code. It reviews the binaries by the compiling them and it has a set of rules that are going to tell you, okay, this is what you need to change and why. And sometimes we even include samples for those rules, you know. So what you're going to see is something like this, you know, a console in which we have analyzed an application. We have a list of applications and we'll get the dashboard with the rules that were triggered by this application. The mandatory, the optional, the potential. And also, for example, if we selected to move to containers, we'll have cloud mandatory rules that were triggered until you look, you need to change this kind of code that you have into something like this with links to documentation helping you do so. So the web console, again, to help you analyze the application and review it. These are some examples, you see, on the left you get a list of issues. You click on the issue and you see on the right the report on what needs to be changed and why. In this case, it's an enterprise database XML definition that is specific to web logic that if you want your code to be more portable and you want to bring it to JEE. Standardized application servers. Well, you could consider modifying this. Again, the IDE plugins. One example here, you could review the code directly with MTA with the migration toolkit for applications. And it's going to tell you, okay, these are the things that I found. This is the explanation on what was found and recommendations on how to change the code. And last but not least, the use cases. So as you see, we have rules for migrating from A to B. And some of the things we do are with around application servers, which was the traditional use for MTA, like moving from WebLogic to JBOC AP, from WebSphere to JBOC AP, which are normally just rules that are more to make your application more Java EE compliant. So you just increase the mobility. And also checking the Oracle JDK, checking for Linux in case you have things that are specific to Windows, checking for a Spring Boot and Camel 2. And we are adding new rules to be able to migrate from Spring Boot to Quarkus that are going to be released in the next version, 5.1.0 by the beginning of December. So this is what MTA does. And now a bit of the roadmap, okay, just a tiny thing. Of course, roadmaps are subject to change. So as Marcus has said before, we have the application migration toolkit that is being renamed to migration toolkit for applications. And we have, which is to analyze the code and we have Pathfinder to assess the suitability of applications to run on containers. For example, like on openshift to run on Kubernetes. And we want to put them together in the migration toolkit for applications. So you can go from the assessment part of the application portfolio that you could have to the analysis part, all in the same place. So for the migration toolkit for application that is about to come. As I was saying before, we have, we will have a new web UI based on part and fly for a new operator to deploy it on openshift. We use an operator to deploy it on Kubernetes whenever possible using an operator. And of course the Spring Boot to Quarkus rules. So this is what is coming. So stay tuned and well, and we'll let you know when we have this ready, but it says pretty well baked already. So it will be not long until it's available for all of you. And then the roadmap to integration. We already delivered 5.0. We are working on 5.1. We are designing Pathfinder for the roadmap to integration. And we're going to have an app inventory and we're going to have a stakeholder controls. So it makes easier to control the whole inventory of applications that you have already available. And once we have the app inventory and Pathfinder ready for with their own operator and ready to run on openshift, we'll merge it with the current app analysis tool, the migration toolkit for applications in one single tool that will be available in the conveyor community and will be offered as operator. So you could consume it very easily in any Kubernetes environment or on openshift. So that's all for me. I'm going to stop sharing the screen. So Phil could take over it. Thanks for listening. Phil, the state is yours. Very much just give me a second and I'll stop my presentation there with me. Sorry guys, I don't seem to have the ability to present at the moment. If you give me one second Phil, let me just be able to present because you're not blocked from audio and video sharing. Sorry about the delay guys, okay. Hopefully you can see my screen now. Yeah, we can. Right. Okay. Thanks very much everybody. My name is Phil Katzanaka. I'm in the engineering manager for the migration toolkit for applications. I'll just give you a brief demonstration of the web UI. First thing I probably should do is just just give you a little bit of information as to where you can find more information about the application migration toolkit. Migration toolkit for applications as it's been rebranded. On the developers website, there's lots of information about the migration toolkit for applications. There's a nice overview video. There's the links to all the downloads. We have several different distributions that you can use to perform an analysis. You've got the web console, which you can run locally or you can run with an open shift. We've got the command line interface that Miguel was talking about. The command line interface is the workhorse of the migration toolkit for applications. With all the different distributions that we have, the CLI, the web UI, the plugins that we have for the various different IDEs, they all provide functional parity in terms of what they deliver. They all will accept the same analysis configuration parameters, allow you to analyze multiple applications and generate the same set of reports and outputs. The three different distributions of ID plugins that we have at the moment. The most established one is the plugin for Eclipse and Code Ready Studio, which is Red Hat's version of Eclipse. We've got a Visual Studio plugin and an Eclipse Shea Code Ready Workspaces plugin as well. They're available to use. They're not as mature. They're just available as tech previews at the moment, but we have a lot of confidence that they are working effectively. Please feel free to play with them. From this page, you can get all of the official downloads for the latest releases. As Miguel mentioned, there will be a release 510 coming the first week in December. Other information regarding the migration toolkit for applications. There's some really nice videos that make it very straightforward to install the web UI either locally or with an open shift. These are very intuitive to use. Then we've got all of the links to the official documentation. There's a documentation guide for each of the different modules and a rules development guide. The rules are what drives the migration toolkit for applications. It is essentially a rules engine. You can write rules using XML or Groovy. The content of the rules are executed if you supply the appropriate parameters for those rules to be considered for selection. I'll discuss the rules a little bit towards the end of this presentation. What I'll do now is go into a demonstration and show you the migration toolkit for applications in action. This is the web console. I did a little preparation for this morning and I created several projects just for the purpose of making the demonstration slick. You can see there's four projects there that I created earlier today. Within MTA, the concept of a project is just a logical grouping of applications that you want to analyse as a unit. Typically, these applications will have something in common. When you analyse them as a group, you will be using the same configuration parameters for the analysis. I've created four projects here. One of which is for the traditional use case for the migration toolkit for applications, which was basically taking traditional Java EE monoliths and migrating them across from WebLogic or WebSphere onto EAP, and then assessing them for Cloud Readiness, and also potentially assessing them for suitability for migration from Oracle JDK to Open JDK. Some of the other projects are for the more recent use cases, which is migrating spring bootleg applications onto the course runtime. With the migration toolkit for applications, it is extensible. The rules, although they are very comprehensive and have a rich set of rules, we encourage users to develop their own rules for their own particular circumstances. If their rules are going to be of benefit to other people, then share those rules with the team and the conveyor community, so that those rules can be of benefit to everybody. I want to create a new project and show you the wizard, which will give you a nice overview of the workflow. When the analysis is running, I will then take you through some of the existing reports that we have for these preprepared projects. To create a project, you need to give it a name and optionally a description. Next, we will take it to a dialogue where it allows you to either supply a directory path to where your application archive files are, or to upload an individual application archive. I will use that and go to my application archive files. Choose two or three applications to analyse. These files are uploaded and the next thing it wants you to do is basically choose the migration path. This is the transformation path screen as it stands at the moment. We are all going to have some new icons for the course and run times targets. Before we get this version finalised, you can see that these are the primary migration paths that we support. There are other targets available that you can select, including the advanced options part of the analysis configuration. These are the primary ones and the ones that are most useful, hence these are the ones that we highlight on this particular screen. By default, the EAP 7 target is selected to migrate across from a web studio or a web project to EAP, or potentially upgrade from an earlier version of EAP to the latest version of EAP. We are always working with the EAP team to make sure that our rules are in tune with the latest release of EAP. Containerisation rules are all about ensuring that your application is cloud native, and it satisfies all of the criteria that you would expect. No hard-coded IP addresses, no RMI calls, RPC calls, that kind of thing. It is all of the 12-factor-app considerations that are encoded within our cloud readiness rules for containerisation. We also have some rules to make sure that there are no Windows paths encoded within your application. We also have a set of rules that check for open JDK to Oracle JDK compatibility. If there are any sort of Oracle JDK methods or pluses encoded within your application, we will pick these things up and alert the user to these things. We have rules for camel2 to camel3 migration, spring boot to coax migration, and also for the versions of spring boot that are supported by Red Hat OneTimes. With these applications that I selected, all being traditional monoliths, what I will do is select those four targets at the top and proceed from there. Next, this gives me a list of packages, and what the application does is it is clever enough to use the Maven index to figure out which Java libraries or make up your application and which ones are standard framework libraries that we do not want to analyse and which libraries are things that have been written by the customer and therefore need to be analysed. You can change which packages you choose to analyse if you are not comfortable that MTA has got it exactly right. You can interact with these dialogues, moving packages from the selected included to the excluded as you see fit. My experience is that it is very good at getting the package selection right, and I very rarely have to interact with this dialogue. Click on Next. This is where you have the option to add custom rules. These are rules that you have developed yourself and will complement the set of rules that are supplied as standard. You can also add custom runtime labels. When I demonstrate the reports, I will illustrate what these custom labels are all about and what their utility is. I will not demonstrate just adding a custom label just at the moment. I will come to that a little bit later on in the demonstration. There are some advanced options which allow us to do some additional things such as generating links to export the reports to CSV files, be a bit more selective about which rules get executed, that kind of thing. For the purpose of this example, I will click on one of those advanced options and I will enable the export CSV. You can see here the targets that I selected on the transformation path screen, EAP-7, Clarellianus linux and OpenGDK were all selected. These ones, then there are some additional targets that we can potentially, there is the OpenGDK one there. There are some additional targets that we could potentially select as well. The transformation path dialogue is just a shorthand way of populating this particular field and you can manipulate the field on this screen as well if you choose to. All of each analysis must have at least one target. However, it is optional to have a source. What the source is is a way of making the rules more selective. For example, if you were interested in migrating a WebLogic application across to EAP-7, you would potentially nominate the source of WebLogic rather than leaving the source field blank. That makes the analysis more efficient because what the analysis process does is it says, let's have a look at all of the rules that are available to us. Let's find the ones that have a target that match the analysis configuration target and, optionally, if a source has been nominated by the user, then also select the subset of rules that match the source criteria as well. Clicking next will take me through to the review screen, which just gives you a high level summary of your configuration and then when you click save and run, it takes you into the active analysis panel and shows that this analysis is about to start running. As it runs, it gives you an update along the top, progress bar showing where we are. That's the process for configuring an analysis, selecting applications to analyse, choosing what your target is and adding any additional criteria that you want to be active during the analysis, such as custom rules and custom labels and advanced options. When this is running, I'll just switch over to an earlier project that I created and you can see here that this particular analysis is completed now and this link here is to the reports. The reports can also be reached through the kebab menu. This icon here is to download the CSV file of all the issues that have been generated and there's also the option to delete the reports. If I click on the reports icon, it will open up the reports main page, which is the application list and the way the reports are structured is a reflection of the fact that a project comprises of many applications and there are some project-level reports, which are these ones that you can see here and then for each application, there's some application-level reports that you can drill into as well. The main report is the application list. You'll see the three applications that I selected for analysis with a list of technologies that have been identified by the rules that sit underneath each of these application names. We have a total number of story points, which are how much work we think is involved in migrating the application to its target and a number of incidents and those incidents are classified into different categories such as migration mandatory, so things that you must do, migration optional, things that you might want to consider doing and then there's also cloud mandatory, cloud optional and informational. You can see the breakdown of incidents based upon those different categories and again all this information is driven by the rules. These, Jboss, EAP and JWS, what these are are target runtime labels and this is best explained in the context of the labels legend. Click on there. What you can see is all of these technology tags have been colour coded as green, red or black in effect or dark grey and the green are things that are supported by that particular runtime. The red ones are technologies not supported by that runtime. The dark grey ones have no influence on whether this application is suitable for that particular runtime or not and everything else that's technologies that are typically embedded within an application that aren't linked to a particular runtime are classed as amber which is partially supported. So green is supported, amber is partially supported, red is unsuitable and the dark grey ones are neutral. And then if you click on one of these target runtime labels all of the technology tags are coloured in the context of that particular target runtime label. So you can see for this particular application the blocker to this application being suitable for Jboss, EAP is that it's got a WebXML technology embedded within it and that needs to be replaced by the equivalent Jboss file. All of the other enterprise applications, Java E technologies that are supported out of the box by EAP or highlighted in green and all the other technologies that are embedded or highlighted in amber. If you click on JWS, target runtime label so this is Jboss web server, basically all of the only technology tags that are supported by JWS are the server technologies as you'd expect. So you can see the subset of technology tags that are green for JWS are quite small and you can see all of the Java E technologies aren't supported by JWS. But this is very useful in terms of customers who want to migrate applications that they have running on an enterprise application server such as WebLogic or WebSphere and these are server applications that would be suitable for Tomcat or JWS. So this target runtime label feature is a very intuitive way of understanding whether an application can be deployed at JWS or whether it requires a full enterprise application platform to support it. So that's the main report and as I say, what target runtime label is all about. We have a nice technology bubble map which gives you a list of technologies that are each application embeds broken down by the tiers of the application so we've got view, connect, store, sustain, execute. And with each of these, it gives you details of what technologies have been discovered in the context of that particular vertical partition. But if you want to see this in a bit more information what you can do is click on the individual application and you can see it broken down in a lot more detail by those technologies with the Java E technologies and those technologies which are embedded. So you can see a lot more detail on this particular report which is summarised on the previous bubble map. Also within the reports, we have a dependency graph and at this level, project level, it just shows you the relationships between the main components, the sort of ER files, the war files and the job files that are customer specific if you like, not framework job files. I don't know whether on the presentation you can see it because sometimes hoverovers don't work on loop genes but if you hover over any one of these boxes a hoverover label pops up telling you the name of that particular archive file. So that's the main reports at a project level and then if you drill into an individual application you can see the reports about that individual application. So the first one is a dashboard which gives you a breakdown of the number of incidents that have been discovered by the rules and by the various different categories and by packages. The issues report to me is the really important thing and the issues report is a direct output of the rules so if you would look at a particular issue tells you which file that issue has been discovered in it tells you more information about that particular issue and it gives you a hyperlink to supporting information and the really nice thing is that if you wanted to see the rule that generated that issue you click on that rule and it will expand and it will take you through to the rule that has fired in order to generate the issue. So that's a nice segue into how our rules are structured and what I'll do is I'll just pick a particular rules file and show you how rules are structured and talk you through that a little bit. So the rules, this one is written in XML and all of our rules files have a name that ends with the suffix.winup.xml or .mta.xml and each rule set must have an identifier so this particular rules set is called spring boot actuated corpus so this is one of the spring boot corpus migration paths rule sets. Within there it's defined what the source technology is so it's obviously spring boot and what the target technology is which is corpus and each rule within your rule set has an ID and this rule set's only got one rule in and the way the rule is structured is there's two main parts to it one of which is the when criteria and the second of which is the perform criteria so the when criteria is what selection criteria must the application exhibit in order for the rule to fire and in this case what we are looking for is one of four things either a particular artifact is embedded within the uber jar file which is in this case it's the spring boot actuated artifact or any of these artifacts has been declared as dependencies within the application's POM file and if any of those conditions are true then the rule will fire and when the rule fires what it will do it will generate an issue and the issue will have this title here we place the spring boot actuated dependency with the corpus smaller rye health extension it'll give you an effort which is the number of story points that we estimate the change to require and a categorization so in this case it's a mandatory change it's something that you must do and then you see a message which gives you a little bit more information about what needs to be done and then a link to the appropriate guide in the corpus.io website so that's how the rules are structured going back to the reports the application details report is a nice one it gives you a nice explosion broke breakdown of the healthy application archive file is constructed and all of the job files and more files are embedded within it which is a different way of showing the sort of dependency graph that I showed you before and again lists of issues within the technology grid that I showed you before which is application specific and then another report dependency graph report which is a little bit more granular than the one at the project level because all of the third party jobs that were deliberately excluded when you look at this report at a project level are actually detailed when you view this report at an application level you can switch them off if you want to and make the report a little bit more focused or switch them back on again so those are the main reports if you like within the application toolkit I just go back to the console what I'll show you is some other projects reports that have go back to the projects list so we'll look at the reports for the spring book to Qorgis migration here's a couple of applications that I selected for analysis earlier today click on the second one on the two and go to the issues list you will see the sorts of changes that we are recommending for replacing spring boot modules with their Qorgis equivalent so the first one is you need to replace the spring web artifact with a Qorgis spring web extension so this is a direct replacement of a spring boot module with the equivalent Qorgis extension as you can see here there's an awful lot of content for migrating this application from spring boot to Qorgis so you can see the spring boot to Qorgis rule set is becoming quite mature now going back to my project list project 3 has a custom runtime label so what I did in this particular case was added a new custom runtime label into the analysis configuration and it was called WebLogic and you can see when I click on top of the time labels the definition of the WebLogic target runtime label is included in the legends at the top and the only difference from the EAP one is that WebLogic technologies or classes being supported rather than unsupported so if I was to click on WebLogic target runtime label in the context of this particular application what was read for Jboss EAP is now shown as green for WebLogic so that's what the target runtime labels do and again going back to another one of my previously prepared reports with a custom rule on project 4 and go to the reports go to the issues list what you can see here at the top of the issue list is an issue that's been generated from a custom rule so I was to click on that particular incident and show the rule behind it what you will see Spring Boot Web to Quarkus Custom which is a custom rule that I created earlier today which will fire when it finds an embedded JAR file for the Spring Boot Startup Web artifact or a declaration in the POM of the Spring Boot Startup Web dependency and when that particular condition is satisfied then it will generate this particular issue which is a custom rule to replace the Spring Web artifact Quarkus Spring Web extension so I just based this custom rule on an existing rule within our rule set just for the purpose of illustrating how easy it is to develop your own rules and add them to an analysis and then what I can do is go back to one of my projects 5 and go to the analysis configuration go to the custom rules and add a custom rule browse it and let me find my custom rules folder and then there's three Spring Boot Quarkus ones there none of which will be really suitable for this application but I just want to illustrate how easy it is to add these custom rules and then once they've been added delete that one you can just enable them and the next time you run the analysis those custom rules will fire likewise with the custom labels very easy to add a custom label and the next time the analysis runs it will include that custom label definition into the analysis and generate the custom web logic target one time label on the analysis list yeah these rules are linked to a particular project so project 5 these however the ability to add custom rules and custom labels that will apply to all projects if you wanted to add global custom rules and custom labels then you would just interact with these particular dialogues and what you can see is all of the rules that are provided by out of the box included in your distribution and then also the ability to add additional ones yourself and it's exactly the same process as I demonstrated for the project-related custom rules and custom labels and that's pretty much everything I have to demonstrate at the moment as I said the really important thing that's I need to stress with regards to the migration toolkit for applications is it's extensible we are looking to develop new rules all the time contributions from the community were very well received by ourselves so that could be beneficial to everybody and regardless of which MTA module you choose to engage with whether it's the CLI the web UI the Maven plugin or even any of our IDE extensions all of these different distributions produce the same set of reports so they all provide the same ability for providing configuration parameters and also generating the same set of outputs regardless of which particular distribution you use to do the analysis and I think I'll leave it there thanks very much for your time back to James hey thanks Phil thanks for the great demonstration awesome demo thanks Miguel, Marcus and Marco for presenting supporting in the Q&A hope you all found this session useful I did paste a link to a session survey in the chat we'd appreciate if you could click on that and take the survey also if you want to continue the conversation or discuss this topic or any other topics that are related to migrating your applications and modernizing them to Kubernetes please join pound conveyor on the Kubernetes Slack or again go to conveyor.io click on forum and hit join group we appreciate you joining we will send an email to the mailing list afterwards with a link to this recording and the slides as well so thanks again to the presenters and everybody who joined us today and we'll see you on the next meetup thanks