WEBVTT 00:00.000 --> 00:17.360 All right, I welcome to my talk, simplifying, 00:17.360 --> 00:22.520 keep it, new tools for easier VM management. 00:22.520 --> 00:27.000 Let me introduce myself first, so I'm Felix Matoshek. 00:28.000 --> 00:31.000 It's not on the microphone. 00:31.000 --> 00:35.000 It's only for camera. 00:35.000 --> 00:38.000 It's only for camera here, and there are a lot of people, 00:38.000 --> 00:41.000 so we need to actually work with this one. 00:41.000 --> 00:45.000 All right, so yeah, I'm Felix Matoshek, 00:45.000 --> 00:47.000 Senior Software Engineer Dreadhap, 00:47.000 --> 00:52.000 and I'm working on a Cupert, including its command line, utility, 00:52.000 --> 00:56.000 and Ansible bindings, and also on other parts of Cupert. 00:56.000 --> 00:59.000 So let's have a look at today's agenda. 00:59.000 --> 01:03.000 First, I want to give you a short introduction to Cupert. 01:03.000 --> 01:07.000 Then we'll have a look at Cupert CLI and enhancements to it, 01:07.000 --> 01:09.000 in the latest development cycle. 01:09.000 --> 01:13.000 Then I want to show you how to use an automated VM life cycle 01:13.000 --> 01:17.000 with Ansible, and after that I'll try to give you a demo 01:17.000 --> 01:20.000 of everything, and lastly I'll show you some next steps 01:20.000 --> 01:23.000 for the topics we've discussed. 01:24.000 --> 01:26.000 So first, what is Cupert? 01:26.000 --> 01:30.000 It's a way to run and manage VMs on Cupert netty, 01:30.000 --> 01:35.000 so Cupert might be an opportunity for companies wanting to get to know Cupert netty, 01:35.000 --> 01:40.000 that already half VMs are interested in container workloads, 01:40.000 --> 01:43.000 and all you can do with traditional VMs, 01:43.000 --> 01:46.000 you can do with Cupert VMs as well, 01:46.000 --> 01:50.000 but Cupert brings VMs into the container world, 01:50.000 --> 01:54.000 so you can make use of Kubernetes features such as services 01:54.000 --> 01:56.000 and others as well. 01:56.000 --> 02:01.000 So Cupert netty has to offer something on top of traditional VMs, 02:01.000 --> 02:04.000 and not only that, but it also allows you to combine 02:04.000 --> 02:07.000 virtualized and containerized workloads. 02:07.000 --> 02:11.000 So for example, you could run like an existing 02:11.000 --> 02:13.000 virtualized application on your VM, 02:13.000 --> 02:17.000 and combine it with a new containerized microservice, 02:17.000 --> 02:22.000 and follow this, Cupert extends Kubernetes with several VM-related 02:22.000 --> 02:26.000 custom resource definitions, and provides agents, 02:26.000 --> 02:30.000 and controllers to actually provide the business logic required 02:30.000 --> 02:32.000 to run the virtual machines, 02:32.000 --> 02:35.000 and under the hood it's using LibWirt, 02:35.000 --> 02:38.000 and QMO to run one QMO process per container, 02:38.000 --> 02:41.000 which contains the VM. 02:41.000 --> 02:44.000 And here, just like for a quick look, 02:44.000 --> 02:47.000 how Cupert, which machine CereD, would look like, 02:47.000 --> 02:50.000 I'm not going into the details, 02:50.000 --> 02:52.000 but like only for rough context, 02:52.000 --> 02:55.000 this is like a minimal VM, 02:55.000 --> 02:57.000 that would be a bootable, 02:57.000 --> 03:00.000 and later we'll move in our space and inspect, 03:00.000 --> 03:03.000 so I'll show this here quickly. 03:03.000 --> 03:07.000 Next I wanted to give you a reminder about a topic, 03:07.000 --> 03:09.000 I've given a talk about in the past, 03:09.000 --> 03:12.000 which is since the types and preferences, 03:12.000 --> 03:16.000 and this topic will become a bit more important later in this talk. 03:16.000 --> 03:20.000 And so these are custom resource definitions, 03:20.000 --> 03:24.000 combining resource sizing or runtime preferences. 03:24.000 --> 03:27.000 Runtime preferences are like settings, 03:27.000 --> 03:30.000 your virtualized OS would expect from the virtual machine, 03:30.000 --> 03:35.000 like shaping the hardware of a virtual machine essentially. 03:35.000 --> 03:38.000 And one of each of the ins and certain preferences 03:38.000 --> 03:41.000 can be referenced by a virtual machine, 03:41.000 --> 03:45.000 and later they will be applied to the actual 03:45.000 --> 03:49.000 virtual machine instance, that's then derived from the virtual machine. 03:49.000 --> 03:51.000 And by now, Cupert ships pretty fine, 03:51.000 --> 03:53.000 instance types and preferences, 03:53.000 --> 03:57.000 so we ship preferences for common access like, 03:57.000 --> 04:00.000 Ubuntu, Rell, CenderS, etc. 04:00.000 --> 04:05.000 So you can start right off the box and run your VMs on Cupert. 04:06.000 --> 04:09.000 And yeah, keep in mind just a different approach to creating VMs. 04:09.000 --> 04:12.000 So the full custom, customizability is still there, 04:12.000 --> 04:15.000 if you use the full definition of a virtual machine. 04:15.000 --> 04:20.000 But in most cases, this makes life easier. 04:20.000 --> 04:25.000 So let's have a look at Cupert CLI, which is a call of virtual CTO. 04:25.000 --> 04:28.000 It's a tool with several features. 04:28.000 --> 04:32.000 So first, it allows you to control the lifecycle of virtual machines. 04:32.000 --> 04:37.000 We think like starting, stopping, restarting your virtual machine. 04:37.000 --> 04:41.000 But it also allows you to create VMs, 04:41.000 --> 04:44.000 instance types and preferences. 04:44.000 --> 04:48.000 And for that, it provides a fixed set of flex on the CLI 04:48.000 --> 04:52.000 to adjust the parameters of the objects you can create with it. 04:52.000 --> 04:56.000 So in case of a VM, for example, you could specify the name, 04:56.000 --> 04:58.000 the boot volume that's going to be used, 04:58.000 --> 05:01.000 the instance type of preference, the VM should use. 05:01.000 --> 05:05.000 And all of that is then output it into a manifest, 05:05.000 --> 05:09.000 which I think it's quite nice because it allows for quite nice one-liners, 05:09.000 --> 05:13.000 creating objects directly on your cluster if you'd like to. 05:13.000 --> 05:16.000 But if you choose to, you could also save this manifest into a file. 05:16.000 --> 05:20.000 You can then customize it further or choose to deploy your VM 05:20.000 --> 05:23.000 with a GitHub approach or something like that. 05:23.000 --> 05:28.000 And also it provides other quality of life features. 05:28.000 --> 05:34.000 I would say most not worth the is the remote access to SSH SAP and VINC. 05:34.000 --> 05:38.000 What's nice about it is that you only need the configuration file 05:38.000 --> 05:40.000 for your cluster control plan. 05:40.000 --> 05:43.000 So you'd only need access to your cluster API. 05:43.000 --> 05:48.000 And then you can essentially use port forwarding to access these services 05:48.000 --> 05:49.000 on your virtual machine. 05:49.000 --> 05:52.000 So you can then SSH into your virtual machine or copy files to it. 05:52.000 --> 05:57.000 Or access the screen of the virtual machine. 05:57.000 --> 06:01.000 And there were several enhancements to which to deal 06:01.000 --> 06:04.000 in the 1.4 development cycle of Cupert. 06:04.000 --> 06:08.000 So what's it here? Create VM, gain several new features. 06:08.000 --> 06:12.000 The first feature would be the generation of cloud init configurations. 06:12.000 --> 06:18.000 Before that, it was only possible to specify a base64 encoded string 06:18.000 --> 06:22.000 on the command line, which contained the cloud init configuration, 06:22.000 --> 06:26.000 which is not very user-friendly, I'd say, but was there. 06:26.000 --> 06:31.000 The second feature is the injection of credentials through the access 06:31.000 --> 06:34.000 to credentials API we have in Cupert. 06:34.000 --> 06:37.000 Third feature is support for Sysper volumes. 06:37.000 --> 06:41.000 So you could now bootstrap your Windows guests on Cupert as well. 06:41.000 --> 06:46.000 And then there were many more cleanups and fixes applied to it to deal. 06:46.000 --> 06:50.000 So it's a most noteworthy, is the unified volume import. 06:50.000 --> 06:55.000 And for that, the UX for importing volume city command line was streamlined. 06:55.000 --> 06:58.000 So it's easier now to import volumes for example, 06:58.000 --> 07:04.000 let's say, from HTTP or registry. 07:04.000 --> 07:09.000 And now I want to have a closer look at the first feature here, 07:09.000 --> 07:12.000 the generation of cloud init configurations. 07:12.000 --> 07:17.000 And then what it does is it allows you to log in and use a VM right after creating it. 07:17.000 --> 07:22.000 There's no more need to compose basic configurations of cloud init yourself. 07:22.000 --> 07:24.000 And I have an example here. 07:24.000 --> 07:27.000 So this would be the what city create VM command. 07:27.000 --> 07:32.000 And I'll give it the user flag because I want my VM to have a user called my user. 07:32.000 --> 07:37.000 And I wanted to have an SSH key, which is in this case, 07:37.000 --> 07:39.000 right from file in your home directory. 07:39.000 --> 07:44.000 So feature of the shell, but I think it's quite nice because it allows you to read from a file. 07:44.000 --> 07:48.000 And then below, there's an excerpt of the which machine was created. 07:48.000 --> 07:54.000 And under its volumes, volume containing the generated cloud init configuration was added. 07:54.000 --> 08:01.000 And in this cloud init configuration, the SSH key is statically injected. 08:01.000 --> 08:06.000 So I abbreviated here the key but you get the point. 08:06.000 --> 08:12.000 And my look simple, but in my mind, it's what say it's very, it's amazing. 08:12.000 --> 08:20.000 Sorry, makes life amazingly easy because especially in definite environments where you need to create a lot of VMs and throw them away again. 08:20.000 --> 08:27.000 You now can create them with a one liner and at least for my work makes life a lot easier. 08:27.000 --> 08:32.000 And you could try this yourself, but keep in mind there's no boot volume in this case. 08:32.000 --> 08:41.000 If you wanted to try it, like keep in mind, you need to add a boot volume for it to actually work. 08:41.000 --> 08:46.000 And then I have the second feature here, which is the injection of credentials. 08:46.000 --> 08:51.000 So on the slide before, we statically injected an SSH public key. 08:51.000 --> 09:01.000 And this time now we're injecting it dynamically, which means we're using the access credentials API to read a public key or a password or multiple passwords. 09:01.000 --> 09:04.000 From from a secret. 09:04.000 --> 09:07.000 And I have an example command again. 09:07.000 --> 09:10.000 Again, the user flag for my user. 09:10.000 --> 09:16.000 And then this time I'm using the access credit flag, which would take multiple parameters. 09:16.000 --> 09:21.000 In this case, I'm only using only a single one, which is the source parameter. 09:21.000 --> 09:28.000 It tells the tool to use the secret called my keys to source the keys from. 09:28.000 --> 09:33.000 And below it, and there's another example for which a machine that was created. 09:33.000 --> 09:38.000 And we see that in its access credentials, an SSH public key was added. 09:38.000 --> 09:45.000 And it's using the QMO guest agent method to propagate the public keys into the virtual machine. 09:45.000 --> 09:50.000 So the guest agent is responsible for writing the authorized keys file of a user. 09:50.000 --> 09:52.000 And this works dynamically. 09:52.000 --> 09:56.000 So it sources the keys from a secret called my keys in this case. 09:56.000 --> 10:04.000 And if we change the secret while the VM is running, the guest agent will update the keys in the running which machine. 10:04.000 --> 10:14.000 And what's great about this feature is that it allows you to store your secrets separately from your machine definition. 10:14.000 --> 10:22.000 So yeah, it's best practice to keep your secrets somewhere safe, not in your machine definitions. 10:22.000 --> 10:27.000 And now we've seen a way to deal, which works well at a small to medium scale. 10:27.000 --> 10:31.000 But let's see how we can manage VMs at a larger scale. 10:31.000 --> 10:36.000 For that, I wanted to show you how you can automate the VM life cycle with Ansible. 10:36.000 --> 10:37.000 I hope you all know Ansible. 10:37.000 --> 10:41.000 It's a ubiquitous tool to automate a key tasks. 10:41.000 --> 10:48.000 And Cupid now provides it's own Ansible collection, which is called Cupid Core. 10:48.000 --> 10:55.000 And this collection provides lean bindings to support the most common tasks for Cupid VMs. 10:55.000 --> 10:59.000 It also allows you to reuse existing tooling in the process. 10:59.000 --> 11:08.000 So it makes Wachim machines, Cupid Wachim machines available to Ansible as any other host for Ansible. 11:08.000 --> 11:15.000 And this allows you to use reuse existing content like roles or playbooks if you have them. 11:15.000 --> 11:23.000 So yeah, also because Cupid VMs are now regular host to Ansible. 11:23.000 --> 11:29.000 You can use it to manage data activities at scale as you would with your other host as well. 11:29.000 --> 11:36.000 So you can now easily apply a configuration change or update your fleet of VMs or stuff like that. 11:36.000 --> 11:40.000 And you can get this from Ansible Galaxy today. 11:40.000 --> 11:43.000 It's also shipped by default in the Ansible distribution. 11:43.000 --> 11:48.000 I think we're starting with version 9 or something. 11:48.000 --> 11:51.000 Let's have a closer look at the contents of the collections. 11:51.000 --> 11:53.000 So first we have some modules. 11:53.000 --> 11:59.000 First the Cupid VM module, which allows you to create update or delete VMs. 11:59.000 --> 12:07.000 It's kept lean intentionally, but it still allows you to change most of the parameters found on a VM. 12:07.000 --> 12:10.000 So we've seen earlier the definition of the VM. 12:10.000 --> 12:16.000 There's a template back inside and you could still choose to modify it with the VM module if you'd like to. 12:16.000 --> 12:20.000 And also it allows you to wait for changes to be propagated. 12:20.000 --> 12:25.000 So let's say you're starting stopping the VM or changing a configuration per meter. 12:25.000 --> 12:33.000 Then in a regular Ansible Playbook, you would expect that if your task is finished that the changes are applied. 12:33.000 --> 12:36.000 But for VMs, changes are not like they're not applied instantly. 12:36.000 --> 12:37.000 It takes some time. 12:37.000 --> 12:40.000 So by default it's running asynchronously. 12:40.000 --> 12:43.000 But you can choose to wait for the change to be propagated. 12:43.000 --> 12:51.000 So the next step in your Playbook, then we can build on the top of your or a previous change. 12:51.000 --> 12:54.000 Then we have the Cupid VM and VMI info modules. 12:54.000 --> 12:57.000 That also allows you to look up VMs on a cluster. 12:57.000 --> 13:00.000 If you don't know which VMs are on a cluster. 13:00.000 --> 13:03.000 It supports filters like label or feed selector. 13:03.000 --> 13:06.000 So you could also filter by namespaces. 13:06.000 --> 13:11.000 And if you already know which VM you would like to get more information about that's possible too. 13:11.000 --> 13:13.000 And these modules are read only. 13:13.000 --> 13:18.000 So you cannot change anything about it or about your VM with them. 13:18.000 --> 13:21.000 So it's safe to run them against running with your machine. 13:21.000 --> 13:28.000 You cannot like harm your application if there's something running inside that machine. 13:28.000 --> 13:33.000 And the next is my favorite part of the collection, which is the inventory plugin. 13:33.000 --> 13:39.000 This inventory plugin allows you to populate your inventory dynamically from data on the live cluster. 13:39.000 --> 13:41.000 So this runs against the cluster. 13:41.000 --> 13:44.000 It discovers the which machines on the cluster. 13:44.000 --> 13:52.000 And then it also allows Ansible to connect to these machines by discovering SSH connectivity to the VM essentially. 13:52.000 --> 13:57.000 So it tries to find a suitable Ansible host, an Ansible port combination. 13:57.000 --> 14:00.000 And there's a certain pretty sense to that. 14:00.000 --> 14:05.000 So you could specify a network name on your virtual machine. 14:05.000 --> 14:11.000 And then it would like it would try to find the interface of that virtual machine. 14:11.000 --> 14:13.000 You specify it. 14:13.000 --> 14:17.000 And sorry, I meant the IP address of that interface. 14:17.000 --> 14:22.000 If not, then it tries to find services exposing the SSH of your virtual machine. 14:22.000 --> 14:27.000 So if you have a load balancer, a node port service, exposing the SSH of the virtual machine, 14:27.000 --> 14:32.000 it would try to connect to them. 14:32.000 --> 14:38.000 And if not, then it falls back to the first interface on your virtual machine, which usually is the pot network. 14:38.000 --> 14:44.000 So if you run Ansible in the same cluster as your virtual machine, or at least in the same pot network, 14:44.000 --> 14:48.000 then it would still be able to connect to those VMs. 14:48.000 --> 14:52.000 And the plugin is designed to handle like large scale environments. 14:52.000 --> 14:56.000 So you can do all the usual stuff you can do with other inventory plugins as well. 14:56.000 --> 15:00.000 So you can group and filter by a cluster name namespaces, labels, 15:00.000 --> 15:04.000 it supports key groups, compose variables, all the stuff. 15:04.000 --> 15:08.000 And of course, you can also use it like with tools like AWS. 15:08.000 --> 15:14.000 So that makes it really useful in these cases. 15:14.000 --> 15:20.000 Okay, so yeah, I wanted to give you a demo about all of this now. 15:20.000 --> 15:26.000 I wanted to make this demo focused on folks running Kubernetes and liking to give, 15:26.000 --> 15:27.000 keep it a try. 15:27.000 --> 15:31.000 And the aim is to show you like a complete scenario of all I've shown you before. 15:31.000 --> 15:37.000 So we want to include the CLI and Ansible. 15:37.000 --> 15:42.000 And I'll show you also how you can get a running cluster and connect Ansible to it. 15:42.000 --> 15:46.000 And I want to try it live. 15:46.000 --> 15:50.000 If not, then we can fall back to the slides. 15:50.000 --> 15:54.000 So just let me move this over. 15:54.000 --> 16:11.000 So first, let's create a, sorry, a Mr. Step. 16:12.000 --> 16:17.000 I want to show you how to create a cluster. 16:17.000 --> 16:19.000 But I'll show you later. 16:19.000 --> 16:22.000 So first, I have a running cluster already. 16:22.000 --> 16:24.000 I have the OTTL. 16:24.000 --> 16:29.000 And I want to create an instance type and a preference with that. 16:29.000 --> 16:32.000 So first, let's run OTTL create instance type. 16:32.000 --> 16:40.000 We pass it a name and amount of CPUs and amount of memory. 16:41.000 --> 16:45.000 And already exists because I tried before, so excuse me. 16:45.000 --> 16:49.000 But we can have a look at the manifest which would have been created. 16:49.000 --> 16:55.000 So we see it has two BCPUs and two gigabytes of memory as we specified. 16:55.000 --> 17:00.000 And then I want to create a preference. 17:00.000 --> 17:02.000 I already did this before. 17:02.000 --> 17:06.000 So I'll just show you how the manifest looks like. 17:07.000 --> 17:12.000 So I specified that it should have a CPU to pull it off course. 17:12.000 --> 17:14.000 So the default would have been sockets. 17:14.000 --> 17:17.000 But I want to assign my BCPUs to course. 17:17.000 --> 17:21.000 And I've seen that the preferred CPU to pull it is course. 17:21.000 --> 17:32.000 And next I'll create, I'll create the VM with Ansible. 17:32.000 --> 17:38.000 And for that, I have a playbook, which I'm running in the background. 17:38.000 --> 17:42.000 Well, I'll explain to you what it does. 17:42.000 --> 17:47.000 So this uses the keyboard VM module to create a VM on the cluster. 17:47.000 --> 17:51.000 Then it applies to instance type and preference. 17:51.000 --> 17:53.000 We just created. 17:53.000 --> 17:56.000 I have a secondary network support on my cluster. 17:56.000 --> 17:59.000 So I can connect to the VM on a layer two level. 17:59.000 --> 18:03.000 So it attaches a secondary network to that VM. 18:03.000 --> 18:08.000 And lastly it injects an SSH key statically so we can connect to it. 18:08.000 --> 18:12.000 And this is a bit up to the Wi-Fi now. 18:12.000 --> 18:16.000 So maybe it works, maybe it doesn't get it. 18:16.000 --> 18:20.000 So we have a running VM on the cluster now. 18:20.000 --> 18:26.000 And next step would be to run the inventory against the cluster. 18:27.000 --> 18:32.000 And for that, I have an inventory configuration, which is quite small. 18:32.000 --> 18:37.000 It's using the inventory plugin provided by the keyboard core collection. 18:37.000 --> 18:40.000 We wanted to look at the default namespace. 18:40.000 --> 18:43.000 And we tell it to use a network name called Bridge Network. 18:43.000 --> 18:47.000 That's the secondary network I just added to that which you machine. 18:47.000 --> 18:55.000 And if I run Ansible inventory with this configuration and tell it to list inventory, 18:55.000 --> 18:58.000 essentially this is running against the live cluster. 18:58.000 --> 19:01.000 And that's the virtual machine, which is running on the cluster. 19:01.000 --> 19:06.000 So first scroll up here, there's the virtual machine. 19:06.000 --> 19:08.000 So test VM. 19:08.000 --> 19:12.000 And we see that there's also Ansible host, which is the IP address of the virtual machine. 19:12.000 --> 19:15.000 And the secondary network. 19:15.000 --> 19:23.000 And now I'll run a playbook against this machine deploying HTTPT. 19:24.000 --> 19:27.000 And we see we want to accept that. 19:27.000 --> 19:31.000 So this is deploying HTTPT on the virtual machine now. 19:31.000 --> 19:34.000 So we have like an example application. 19:34.000 --> 19:40.000 And what's important here is that we need to point Ansible playbook at the inventory. 19:40.000 --> 19:45.000 We need to give it a user and the private key we just unchecked it as it can connect. 19:45.000 --> 19:48.000 And this is now up to the Wi-Fi again. 19:48.000 --> 19:56.000 It works. 19:56.000 --> 20:04.000 If not, we can go back to the slides for a second. 20:04.000 --> 20:17.000 Because I told you I would show you how you can create a cluster and actually connect to it. 20:17.000 --> 20:20.000 So Ansible to it. 20:20.000 --> 20:22.000 So I forgot about that part. 20:22.000 --> 20:27.000 For this, we're using the actually the test environment of the corporate core collection. 20:27.000 --> 20:30.000 So this would be step free in the slide here. 20:30.000 --> 20:35.000 That's using Docker or potman to spin up a cluster. 20:35.000 --> 20:40.000 And thanks to potman or Docker, we easily get support for secondary network. 20:40.000 --> 20:43.000 You can run all of this yourself. 20:43.000 --> 20:48.000 I uploaded the slides to the first page and should all work. 20:48.000 --> 20:51.000 So you could just copy and paste it and it should hopefully work. 20:51.000 --> 20:54.000 If not, you can contact me. 20:54.000 --> 20:55.000 I'm happy to help. 20:55.000 --> 20:58.000 So please try it yourself. 20:58.000 --> 21:05.000 And I just see that the playbook was applied successfully to the VM. 21:05.000 --> 21:09.000 So I want to show you actually the other works. 21:09.000 --> 21:20.000 If my VM is working, then yeah, it is. 21:20.000 --> 21:25.000 So the IP address of the which machine was this here. 21:25.000 --> 21:30.000 And if we go there, we see actually the HTTPT is running on the which machine. 21:30.000 --> 21:32.000 So it worked. 21:32.000 --> 21:36.000 The Wi-Fi was nice to me. 21:36.000 --> 21:51.000 So now the slides are completely broken, but that's fine. 21:51.000 --> 22:02.000 Can show you the slides anymore, but. 22:02.000 --> 22:09.000 Anyway, I just want to conclude what we've did in the demo. 22:09.000 --> 22:14.000 So we successfully created a cluster with the test setup of Cupid Core. 22:14.000 --> 22:16.000 We connected. 22:16.000 --> 22:23.000 Ansible to it with the inventory plugin and we created a VM on that cluster. 22:23.000 --> 22:27.000 And we successfully deployed an application on that cluster. 22:27.000 --> 22:31.000 And lastly, I have some next steps, which I'd like to show you. 22:31.000 --> 22:35.000 Okay, some few more next steps. 22:35.000 --> 22:42.000 So in the future, we wanted to make work to deal more easy to extend because right now there's still some some boilerplate code involved in it. 22:42.000 --> 22:45.000 We need to address some usability issues in Cupid Core. 22:45.000 --> 22:53.000 So there's still some issues if you run it against the cluster and the VM is modified in the in the same moment. 22:53.000 --> 22:56.000 And there can be identity issues with Cupid Core. 22:56.000 --> 23:00.000 And lastly, we want to carefully at the features to the collection. 23:00.000 --> 23:03.000 One big feature would be support for fact caching. 23:03.000 --> 23:05.000 And lastly, we need your feedback. 23:05.000 --> 23:09.000 We need to know from you what you would like to see in the collection in the future. 23:09.000 --> 23:11.000 And that's it. 23:11.000 --> 23:12.000 So, thank you. 23:12.000 --> 23:19.000 Any questions? 23:19.000 --> 23:24.000 Yeah? 23:24.000 --> 23:26.000 Yeah? 23:26.000 --> 23:27.000 Cupid. 23:27.000 --> 23:29.000 I will also talk about the public cloud there. 23:29.000 --> 23:34.000 I would like to add a draw and go over. 23:34.000 --> 23:40.000 If I understood correctly, the question is, is Cupid supported on public cloud's AWS? 23:40.000 --> 23:49.000 Actually, you can just deploy it on a regular Kubernetes cluster. 23:49.000 --> 23:52.000 You can run this cluster yourself or you can use a managed cluster. 23:52.000 --> 23:54.000 This works. 23:54.000 --> 23:58.000 For it to work optimal, you would need bare metal notes. 23:58.000 --> 24:04.000 But you can choose to run nested virtualization, but it's like it's dangerous territory. 24:04.000 --> 24:06.000 It can work, but it can cause issues. 24:06.000 --> 24:08.000 But in general, it works. 24:08.000 --> 24:12.000 You can deploy it on a cluster on a public cloud. 24:12.000 --> 24:17.000 Can you do both of the public vendors like Microsoft and Amazon? 24:17.000 --> 24:24.000 If the question was, is it supported by vendors of the clouds? 24:24.000 --> 24:27.000 If you run it yourself, then it's not supported. 24:27.000 --> 24:32.000 It's your own application, but there are offerings based on Cupid. 24:32.000 --> 24:35.000 So you can find them some clouds. 24:36.000 --> 24:41.000 Any more questions? 24:41.000 --> 24:47.000 And that's it. 24:47.000 --> 24:48.000 Thanks.