 Thank you. Okay, let's start. So welcome to this presentation. My name is Kevin Boumedel, and you're going to see a presentation called Use Calcly with all your virtualization solutions. So first, some words about me. I'm a senior software engineer at Red Hat working on Covert. Here are some of the things I like. I like my guitars, piano, and so on. I like rollerblading. I like Python much more than Go, actually. And I like studying languages, Arabic, Berberian, for instance. Cool. About the agenda for today, I will talk a little bit about focus and automation. Then I will explain in this context what Calcly is, why it helps me. I will provide some additional facts. Then it will be time for live demo using this network, so we'll see how it goes. We will do a recap. And finally, we will have, hopefully, some time for questions. Let's begin. First, we have a couple of words about focus and automation. I want to convey the idea that it's getting more and more complicated to focus because we have things getting in the way like Facebook, Twitter, WhatsApp, Telegram, YouTube, or other stuff, right? So I really believe it's about finding the right balance between automating the boring parts and focusing, again, on what's relevant. So I must see something, guys. So in this context, I created a cool tool called Calcly. So what is Calcly? It's basically a client tool meant to interact with virtualization providers. And I mean leverage, but then it evolves into something that helps me ending covert, GCP, AWS, overt, and open stack. The idea is to easily manage VMs from command lines the same way, regardless of the platforms that you want to use. There's then also a construct which is called plan files, we will see what it is, which allows us to declare VMs or other objects like containers, networks, pools, disks, and so on, right? And then we are also able to share them using the concept of repos and products. There's Jinja support in those plan files which means that you can leverage Jinja constructs to actually declare variables use looping or conditional stuff. And there's also support for containers whether docker containers or Kubernetes objects pod or deployments to be actually accurate. There are existing plan files that I developed to deploy things like Kubernetes, OpenShift, Covert, Overt, OpenStack, Forman, and so on. There's even a web interface done in Flask which is probably crappy, but that's not relevant, I guess. Then let me provide you with some additional facts regarding the installation. You can deploy it either as a container or you can, a container that you can deploy with docker or podman to be accurate. Or you can also use an existing package so it's either RPM or DEB. In which case we only bundle lever dependencies to make those packages more. Right? There's an ecosystem around CACLY because CACLY is also a Python library. So it means that we can actually use NCBLE modules through CACLY. There's a dynamic inventory which lever is CACLY and there's even a Kubernetes custom controller that you can use to declare VMs there. So in all of those cases, I believe that the interest is that you have a single tool, right? Like, for instance, the dynamic inventory. You use the same dynamic inventory regardless of whether you're using Overt, Livert, OpenStack, and so on. And the same with the NCBLE module, a single NCBLE module, whether you're using GCP or AWS or Overt or Covert, whatever you have in mind. Okay, about the roadmap, the idea is mainly to add new providers, DigitalOcean, Azure, IBM Cloud, and Alibaba Cloud which I believe are the top cloud providers which are currently not coded in this tool. About weaknesses, there are some weaknesses I believe. So typically I believe that the documentation should be improved in particular the installation process. Then you need tests. I removed them at some point, but they are not back, but they need some shaping. And the logo offended the logo and probably it needs some improvements too. Okay, that's pretty much everything I wanted to cover. I didn't want to talk too much, but I already did talk too much. So let's go with the live demos. The idea is to show you how to do bootstrapping. Then we will create a VM in several places. We will use these profiles. We will use plan files. Then I will also explain how to deploy Covert and OpenShef, for instance, using product. And if we have enough time left, I will probably show you the web interface and maybe NCBLE integration. Let's try. Let me switch to this. Okay, I've got clear. And I will begin with this first... I'm going to try it with your stuff, by the way. Let's see if it works. Yes. Okay, so this demo is just bootstrapping, right? So what we want to do is just create a first provider and we want to launch a VM on it. Simple. So first I'm going to delete my existing caclyconfig file, which is stored in this directory, config.yaml, okay? And I'm going to use this command, caclybootstrap, to actually bootstrap this libret client. In this case, it's a remote one. Of course, I could also use my local libret, not in my case, but if you even Linux box. Okay, that's simple. This got bootstrapping and basically what it does is just creating this file, config.yaml, okay? Well, I want to show you... There's a default section over there, right? When I'm saying which client I want to use, it's caclyaml, then I'm setting default values for all the parameters that you can override. That's fine. And then there's a corresponding mylibret section with the name I put, where I say I want to use this remote hypervisor with default value and using SSH as a URI. Let's try this. Okay. Indeed, I can see my available clients, right? I've got this mylibret one that I just created along with a fake one that I use just to do testing and it has some other utilities, but it allows you to test cacly without any provider. Good. Okay. Once I'm there, what I will typically do is download Cloud Image, right? The idea is to leverage existing Cloud Image. So with this cacly download command, you can download either CentOS, Fedora, Ubuntu, Event Rail, or Debian Cloud Image so that you can create VMs from there. Let's see which one are available for this hypervisor. So I previously run cacly download CentOS 7 and so CentOS is there. So I want the CYROS run. I would do cacly download CYROS, so it's communicating with my mylibret remote instance, which is running at home, by the way. And it's downloaded it. And once it's finished downloading, we can see it's there. Cacly lists minus templates and I would be able to use this to create a VM. Okay. So let's create a VM finally. It's as simple as that. We specify the template that we want to use, right? And the name of the VM, VM1, okay? Cacly VM minus P and the VM got created. It's easy, okay? In this case, we are using default values for things like a CPU's memory. If you want to tweak this, how do we do that? Very much the same command that we can see that we are passing additional parameters. In this case, the memory, right? Two gigabytes VM and I'm also specifying the disks. I want the VM to have two disks with the indicated size. Cool. Now if I use Cacly list, I can list the VMs that are running in this hypervisor, right? VM1, VM2, they are there. And you can see that the IP is also shown. It's not really properly formatted because of the output, but that's fine, right? I can see the name of the VM and the IP and so on, right? So since I have the IP, actually I'm able to SSH into the VM. Cacly SSH VM1. I will connect to the VM. And you can see that I'm using the CentOS cloud image. I'm connecting a CentOS user. We are detecting the cloud user depending on the template that we want to use. And also you note that I didn't provide any password because my public key got automatically injected for me so that I don't have to think about it so that I can focus. Okay, cool. Let me exit this VM. Okay. And then I can delete my VM. VM1, VM2. In this case, I'm deleting with a single command line, right? VM1, VM2. Just to wait a little bit. And my VM is deleted. That will be my first demo. Let's go with the second one. This one is called a VM everywhere. So it's going to be pretty much the same stuff, but now we are going to create a VM not only on Libvert, but on other parts. Good. Let me first establish my own config file, which is a bit more complex. And you can see that indeed, mine has not only Libvert or KVM, but I also have AWS over KVM. I've got GCP, Covert over OpenStack, pretty much all of them. Good. Let's create a VM in my default Libvert client. We already did that. So it's pretty much the same. VM10 is getting created. That worked. We are happy. Okay. No. Let's do the same, but in this case, I'm going to create it in my GCP account, right? So for people familiar with that, I don't have to use the cloud, which is fine, but you need to learn it, okay? And it's created. Let's do the same with AWS. So in this case, AWS, I never use the AWS client, so I can't talk about it. I just use my tool, right? So under the hood, I have to indicate that when you attack GCP or AWS, you don't download the template. You use the existing cloud image from the corresponding cloud provider, of course. Okay. Good. If I list... Yes, I need to be careful with this. The VM on my default provider, right? They are there. The VM10 I created. If I list them on my GCP provider, so I'm just pointing to a different client, as I call them, right? I will see the VM that I've got there, so cover stuff, but also my VM10 is there. And the IP showing, so I could be... I would actually be able to say caclyssh, the same way that I did earlier. Okay. Let's finish with AWS. Pretty much the same. We try to also have the same output, regardless, again, of the virtualization that we want to use. And of course, we would do the same for covert, overt, or open stack. The same idea. Okay. Now I'm going to delete the VM on each of them, so it's pretty much as we did earlier, so that you just want to know that I'm specifying several clients, so I'm actually deleting sequentially the VM over there. And that's pretty much it. Let's go with a third demo. Okay. This one is called profile. Of course, because up until now, we have evacuated the VM with default settings, right? Or we specified part of the setting using common line, like memory and so on. That's fine, but we can do it better, right? So we are going to use profile. Profile are basically defined in the caclyprofile.tml file, right? So there are a bunch of them, but just let's focus on one I've created, which is called force them. So in this force them profile, I'm specifying that I want to use a template, which is optional. I want to use the centers one. I specify the number of CPUs that I want to use. Domain with the DNS is set to true, which means that the DNS entry will be created in this case in Libvert, or if I use GCP that will be created as a public DNS entry. I'm specifying that I want to disk with size 10 and 20 and so on. I think it's fairly readable. I'm also executing some command at launch time through Cloud in it. So I'm setting a custom mod here, as you can see here. And I'm also using notify, so you should see it here, but there's some push-ballot integration. We can also use caclyprofile. It's pretty much the same output, right? It doesn't show well because of the output, but that's fine. So let's create a VM with this profile. So the VM is named from the profile force them. Sorry. Since I'm not specifying a VNM, a random one is picked for me, right? This one is called instant write, and now it's deploying. Since I specified reserve DNS and set it to true, I'm actually waiting to collect the IP that I received through DHCP, and once it's done, the DNS entry will be created. There's also support for static networking. Okay, cool. If we check the info of this VM with cacly info, you can see the information, right? Again, the NICS, all the information is visible, and again, it will be the same regardless of the platform, right? Yes. And also just note that for most commands, if I don't specify a name for the command, the last created VM on the corresponding current provider is the one used, so the one I just created. Good. Let's connect to this VM, and for instance, we will check that the DNS entry was created along with custom mod D. You can see the custom mod D is there. If I do a ping of the VM, right, you can see it works, and you can't, I think you can't show it, but in my notification over here, right, you can see that because of the push-ballet, just right now, I've just received the information. So it's quite full, of course, not when you create a simple VM, but when you create several ones and you want to verify that things worked well, you can use that to launch a command and receive a notification on your phone or so on. Okay, cool. Let me exist. Okay, and finally, I will delete this VM. That's cool. Nice. I've got more demos. You tell me when you're bored with my demos. Okay, this one is called plans. Let's see what a plan file is. The idea behind the plan, it's come from the Terraform stuff, if you're familiar with that, more or less, right? But the idea is to pretty much create multiple objects at once and handle them as an entity. Let's see. This is a simple plan, right? So it will just create three VMs, VM1, VM2, and VM3. If you really have a look, it's pretty much the same syntax as the profile, technically, just that it's used in a different context, right? And by the way, I could be referencing here any profile that I've created, or I could even define a profile within this plan and point it directly. So I can do it whatever the way I want. Okay, so this one will create three VMs. So let's launch the plan. Calculate plan, and it's going to deploy my three VMs, VM1, VM2, and VM3, hopefully, turning on my NUC at home in this case. Okay, so VM1 got deployed, VM2 got deployed, and VM3 will get deployed just right now. Okay, cool. So we can see that the objects are there. We've calculated this as we did earlier. So I think you understand how it goes now. Okay, VM1, VM2, VM3, we've got the IP again. Okay, of course, if we rerun the plan, right, it won't recreate the VMs. It will keep them because they already exist. Okay, now if I delete one of the VMs, VM3, for instance, yes, and we run the plan. In this case, of course, the missing VM will get recreated. There's also support, by the way, to actually run the plan with a minus-minus update flag so that if you change some elements of the plan, then the VMs are updating accordingly with a memory, CPUs, the disk or the NICs section. Okay, we can also handle all the objects of the plans at once. For instance, we can stop all the VMs just by using plan minus-minus stops or start. There's also a start. We can even delete the plan at once. That's easy. And again, I insist that in this plan, it's not only about VMs. You can create your own Libert networks or your own networks, regardless of the visualization platform. You can create containers. You can create disks and so on. Okay, here's a more complex plan. Don't get scared, right? But just so that you understand, this one is using parameters. So what it means is that we define a default parameter section. We say no to free. We define whatever variables that we want, the template, the domain and so on, some keys, right? And then we use Jinja to loop, right? Using these parameters. And then we use whatever parameters we want, right? There's also a file and script section that I can use to actually inject files within my VMs or scripts to actually run script that is some arbitrary commands that I want to use. And they are also rendered. So that means that if I have a look at the file that I want to inject, it can either be static or it can be Jinja, pretty much. Okay, the same with scripts. I want to install all those packages, right? And I'm using the package variable that is defined over there. So with that, I can actually launch my plan with this command, right? So pretty much what we saw earlier, but the difference is that I'm actually forcing overriding some of the parameters. So remember, nodes was set to free, for instance. So in this case, no, I set no to five. So I will create not three VMs but five, right? And the disk size was one of the parameters. So I've just overrided. So instead of disk set to 20, there will be set to 30. And indeed, I can see that not only did I create those three VMs, but now it's going to create the two of the VMs, right? And I could rerun the plan with a different node setting. Let's say a node set to 20 and it would recreate the missing VMs. Now it's when I need to wait because I want the IP to be there. I've got five minutes. I'm good. I'm good with that. That's fine. Okay. Calculate list. Okay. Just one Calculate list because I just want to, for the workflow of the demo, to be sure that I'm able to SSH to the VM. So I can. So indeed, let me just remove that. Right? I can SSH, right? And we can see, right, that I'm connected, cloud init and all that stuff. But if I do a sudo minus I, right? I can see my file and we can see it's there and it's got rendered, right? With whatever parameters I set, for instance, the node set to five. So you can pretty much create whatever you want. That's the idea. Good. Let me exit. Yes. And I would conclude this demo. I've got one left, one left. This one go with product. Okay. So products are pretty much the same idea as the plan file. The only difference is that we want to, they sit on top of them to make them easy to redistribute, redistribute, sorry, and to use for people not wanting to deal with plan details. Okay. So how does it go? I create repo, right? This is my repo. This is my URL where I'm storing those plan files. And actually it's just a git repo that is cloned. You don't calculate slash plans, right? So those are all the plans I have, along with this Kmeta file which contains metadata. I've got this metadata. And since I'm able to browse it, I can see all the available products at my disposal. So I've got all those samples. Then I've got, it doesn't show very well, but OpenStack, OpenShift, Kubernetes, and so on. So let's go with one of them. For instance, I can list the products of a given product. For instance, OpenShift. I can deploy whatever I want. For instance, Fission, Federation, if you want to deploy to VMs, and so on. Let's deploy one. Sorry, first, let's get information on one of the product. Covert. I want to deploy Covert. I can say Calculate Product Covert minus, minus info. And I see description of the plan. And then pretty much those are all the parameters that you can override. Under the hood, it's using this plan concept. Let's say I want to deploy Covert. Calculate Product Covert. You've got Calculate Install. You've got an available provider somewhere. And you are pretty much deploying it. It deployed. Once Cloudy is finished, you've got Covert installed. Let's install, for instance, OpenShift, right? But in this case, I'm going to override some parameters. So it's pretty much the same. But I'm saying, yeah, deploy Origin using OC Cluster App. We don't care how it's deployed. I just want OpenShift, technically. And I'm setting Knative to 2. It will install Knative, STO, whatever it has to install. And of course, I can check VM. And I can see that my VM got created. Yeah, Covert, Origin, whatever VM. The one that it didn't delete. OK, I think I'm going to stop here because I don't want to do too much demo. So let me get back to this. We did the demo, right? So just to recap, automating the boring stuff, right? Always trying to focus. And in this context, I believe that can be the tool that at least helps me in automating the infrastructure. Whether you've got one single liver, you have got several ones. You're using overclock providers. I think it's an helpful tool. So feel free to use it. And now if you have questions, it's going to be the right time. And if you don't have questions, just this picture that I put, it's an optical illusion. If you focus, but it's going to be difficult because it's short, but you can come closer if you want. But if you focus on whatever part of the picture for like 10 seconds, you should see other image blur and turn white. If that doesn't work, it's because you're too far away. Sorry for that. Any questions? No, it's the time. Go ahead. OK, the question was, can you include information in the plan file so that you deploy VMs across several cloud providers? More or less? Yes, you can. I didn't show it, but one of the parameters that you can use in the plan file is also specifying which client you want to create for a given VM. So you can say, create me a few VMs, but two of them on this cloud provider and the last one on this one. And the same for DNS, by the way. Last question, I believe, because I'm out of time. Does that make sense in provision with Ansible, for example, a VM would create? That's a good question. Sorry, first I need to repeat the question. The question was, can you use it along with Ansible to fully provision a VM? Yes, there are different ways you can do that. There's the dynamic inventory. There are Ansible-Cackly modules. And then there's Ansible integration in the plan files, which means that when you create the VM, you can just let Cackly create the VM. And within the plan file, you can specify an Ansible or some Ansible playbooks that you want to run along with Cackly. You like it? Thank you. Yes. Thank you. Thank you. Is that yours? No, this is yours. This is all mine, yes. Thank you. How are you? Very nice presentation. The only detail, I have only one remark. Wide line. I crossed it too much. Yeah, I knew it, man. But you didn't say anything. My friend, I guess I'm good. I have a request. If you... Here is the guy who has questions. Please take those slides because we need to answer the speakers. Let's start with questions outside. Thank you for your great presentation. Yes. Yeah, we can talk French now. Ah, thank you. It's great. Excellent. I was doing that and it's beautiful. Did you like it? Thank you. I started doing the same little tool to integrate Olivier and other things for my Blue. And I'm using it now. It's great. Thank you. I like it. Oh, okay.