 Hola, everyone, this is Miguel Perez-Colino. I'm a product manager in Red Hat. I'm working in the conveyor community. And I want to tell you about conveyor, and I want to tell you about the tools that we are using. And my colleagues, John Matthews and Fabián Dupont, are going to do a couple of demos. So before we start, let me introduce you. John is an engineering manager that is working in container migrations with the migration toolkit for containers that has a project in conveyor called Crane. And Fabián is an engineering manager for Forklift that has a downstream version, which is called migration toolkit for utilization, intended to move virtual machines from VMware to operationalization to Quipvert on Kubernetes. So let's get started about conveyor. Next, please. So conveyor is a project community in which we're passionate about moving workloads, moving things from A to B, making them portable, and understanding the patterns and discovering the patterns that make you be able to become more cloud native. So the idea is that you can modernize your workloads and turn them into possible containers running on Kubernetes so you can get all the benefits from doing so. In that journey, there are different paths. And of course, moving VMs into Quipvert could be a path that will set you in the base camp where you can have your VMs next to your containers. And moving containers from one cluster to another is another of the paths that could help you in the way. So there are five projects right now on the conveyor. Forklift to move VMs, Crane to move containers, Move to Quip to move from all the kind of containerize or so the containerize environment, such as Cloud Foundry, to Kubernetes, Tackle to analyze and assess applications to be able to modernize them and put them in containers and then Belarus to make measures on the improvements that you're going to do along this journey. And of course, as we read have, we have our downstream supported toolkits that are based on these projects, the Migration Toolkit for Applications, which is based on Tackle, the Migration Toolkit for Containers, which is based on Crane and the Migration Toolkit for Materialization, which is based on Forklift. Next, you could see these projects as we say first one Forklift to rehost to virtual machines. Next, we have also Crane to rehost the container. Next, we have Move to Quip, as I already mentioned, to replatform. Next, Tackle to refactor applications, Java applications to Kubernetes and next, Belarus to make the measurements. Next, and this is completely aligned with the 6R framework that we all know, we have replatform, refactor, retire, retain and repurchase that everybody is using right now to modernize their workloads. So we want to align all these tools to all these cases. So whenever you want to do rehost, you could use Crane or Forklift. When you want to do replatform, you use Move to Quip and when you want to do refactor, you could use Tackle. So today we're going to see Crane and Forklift and John and Fabien are going to go through it. Next, and this is it. Next, now let's see the Forklift demo that Fabien is going to do. Fabien, the stage is yours. Thank you, Miguel. Just a few words about Forklift. As Miguel introduced, the goal of Forklift is to migrate VMs and more precisely to do mass migration. What we try to achieve is provide a tool that allows you in very few steps to move a lot of VMs directly from VMware to achieve virtualization or convert. And all you've got to do is provide a source and destination credentials, map the infrastructure and create a migration plan. The migration plan then runs and your VMs are on the destination. We also have a migration analytics component that is detecting potential compatibility issues so that you're not trying to migrate VMs that are not suitable for convert. So as a user, the first thing I need to do is add the source and destination providers. Here, source in VMware, destination is convert. But then I create a plan. The plan is linked to one provider's yard, the source, because we all go through convert. Then we list the VMs we want to migrate. So we've got it from the provider inventory. And then we do the mapping of the source and destination. Say you come from a specific data store on VMware site, you want to go to a specific storage class on convert. Same goes for the network. You can even use multist to use native VLAN or SRIOV fancy networks features. From there, the user will create a migration CR. Migration CR is instantiation of the plan. We want to run the migration so we click or we create a new CR for that. And behind the scenes, we're using a component called VMIO that does import a single VM. So for each VM, we're creating one single input and we are orchestrating all the inputs, allowing us to have throttling at the VM and plan level. I mentioned the validation service. Actually, we know that some by migrations will fail. So what we want to do is one, don't block. It's one of our motto for a long time and we want to expose the user the concerns we have. And we also want to fail fast. We don't want to discover after the migration that the VM is not suitable. And we've lost time by shutting down the source VM because that is not going to work. We have an extendable and multilevel rule set as code and it generates concerns. Every time it finds a rule is matched, we've got a concern and we expose a concern in the client creation result because we've got a UI. I mentioned CR, but we've got a UI anyway and I'd show that. Now, the plan condition reflects the validation. So you know when your plan, that the plan is suitable to be migrated or run directly. And we also provide a pre-migration analysis at scale. We're doing the analysis before you even create a plan. So you can have all the information right away. For that, we are using a pen policy agent that is when learning the communities ecosystem. And if you want more information, here is a link. Quickly over a demo that will show you the user interface. So the third thing we do is add a source provider. Here, I'm adding VMware, providing the name, the host name, credentials, and my provider is created from there. Behind the scene, we run an inventory container that provides all this information about the VM, the host. Next, I'll go and create a migration plan. Let's call it demo. I select the tools provider I just created, the destination. Host is actually the open chip cluster or the Kubernetes cluster and the operator is running on. So it's created when you deploy the, when you deploy forklift, you don't have to do it manually. So we're gaining some time there. Then I'm selecting VMs. So you can see that there is some filtering. You can also see the warning. All the VMs in this cluster have at least one warning is due to DRS being enabled on the cluster. On the list of VMs, I will create a mapping. So I say that all the networks that are used by the VM will go to the pod network. My cluster is quite small. I don't have a lot of networks. Same rules for the storage. All the data stores used by the VMs go to stand up. That's all. I just click on finish. My plan is ready to run and I click start. If I go into the plan, I can see the details of the process, of the progress. My VM is 20 gigs. After some time, both VMs have been migrated. We can see the different steps and it's complete. I can go into the Kubernetes or open chip console and see the result. Here I have my two VMs. I'm just starting them from the QBert interface. And because I'm playful, I'm going to show you the VM running Windows. That would be too easy to show a Linux. And from the console directly, I can access the virtual machine console. So it's console inside a console kind of inception. But you see the idea. We've got access directly to the Windows machine that has booted. So that was it for the forklift site. I'm handing over to John for the crane part. Thank you, Fabian. I just need to switch out the screen share. Yeah, great. So I want to take about five minutes and give you a short overview of crane. Crane is a tool that we built to help with stateful application migrations across Kubernetes clusters. A typical use case of crane could be that maybe you have an older cluster and you have an application that's been running there for a year or two, and now you have a new cluster it's up and you want to migrate that application to the new cluster. And the important thing is that a lot of these applications you want to migrate, they may have state. So you can't just redeploy the application. You need to be able to migrate it and bring it state with you. And crane is a tool that we built up out with that. When we talk about a stateful application, there are essentially three buckets of things that make up that application. There are Kubernetes resources. This could be your deployment, secrets, services, things like that. There could be potentially internal images that were built for the application that are required to run. And then also state and persistent volume data. And crane will migrate all of those three things to the destination cluster. So your application will be running and you'll have that state in the destination cluster that you originally had in the source. As we recall, under the covers, crane uses several tools to accomplish this. And one of the popular tools that we use is Valero. Valero is helping us to do a lot of the backup and the restore operations to enable this migration. I just want to show you quickly how you can install crane. If you have operator hub installed on your cluster, you can search for crane. And from that you will find the crane operator and then you can bring that into your cluster. And let's just take a minute to look a little bit at the UI. I have about two, three minutes. So I'll go over this quickly. I won't be able to run a migration, but I can show you the basics of how this works. Everything in crane is like most things in Kubernetes. It's driven from a custom resource API. Everything you see in this UI, we can do from the API directly with custom resources. So we look at the UI. It starts out where we have two clusters defined, our host and our source cluster. And we also need an object storage to temporarily house some of the data. So we have one configured here. The heart of this is creating a plan. And a plan is where we describe what we will migrate and how we're gonna migrate it. So we'll create a plan. And first thing is we just give it a name. Then we pick out our source cluster and then we pick out a host cluster. And this is the destination of where we're gonna migrate to. Next up, crane is going to look in the source cluster. It's gonna find the namespaces that exist and give us a little bit of information about those namespaces so we can pick out what it is that we wanna migrate. In this case, I wanna migrate the parks app. So I'll select that namespace. I could select other namespaces as well if I wanted to, but we'll just do one. Now crane will take a few seconds to look inside that namespace. So looking at parks app and it's finding out what are their persistent volumes that are being used by that application. So we can see here that we found one persistent volume. It's backed by a GlusterFS storage class. See it's 10 gigs. And we have an option of copying it. For some other kinds of PVs, maybe something more remote storage like NFS, we could do a move as well. But in this case, we'll go with a copy. So next we have a few copy options that we could change. We could do a file system copy or we could do a volume snapshot. We'll stay with a file system copy and then we can also pick out the storage class. In this case, we're gonna be going to an EBS back storage class. So if you notice here, we had a source application that's being backed with GlusterFS storage and we're gonna migrate to a destination. It's actually using EBS. So it'll be changing the storage type when we do this. And then we have some options that just are verifying that we do have the ability to do direct image and PV migration. They'll make this a little bit quicker. And the last piece is that we could augment the migration and add other steps. Maybe if there's something that before we do the migration we want to do something off cluster, perhaps change a load balancer, take an application out of rotation, something like that. You can add some ansible hooks that would run with a migration. So that completes creating the plan. Now you'll see that we came up with a few warnings. And this is because we have validation logic that will look for anything that could be abnormal and let you know about this before you go ahead and do the plan. In this case, it's telling us that there was note selector being used in the source side and we're going to clear it so it doesn't impact when we do the migration. So that is the main piece of creating the plan. The next step to execute it would be to go here and click on migrate and then it would start to execute. Since we don't have all the time, I'm going to end that portion right here. So crane is a tool that can help you to migrate stateful applications across Kubernetes clusters. And we go back to Miguel. Sorry, Miguel, I think you're muted. So thanks a lot, John. Thanks Fabien. Sorry for the mute. Of course we would like you to join the conveyor community. Please go to conveyor.io and find more information next, please. And you could see in conveyor, of course that you could browse to the page, go to contacts, find, join the community and then you will get invitation to see the meetups. And even if you propose something you could also join and provide a meetups and get early access to the code and access and build up tools. Next, please. So thank you very much for listening and see you in the conveyor community. Bye. Thank you.