 Hi, I am Francis at locale quality engineer in Ferrera QE and today I'm going to talk about test cloud What is test cloud test cloud offers a simple way to create the full blown virtual machines? You can use it anytime you need to test and break something during development and containers aren't enough for you You can use its command line interface or an integrated via Python API to rescripts and projects Test cloud comes with workarounds for some distributions that need them in some some modes How does it work? It's pretty simple. You ask for a virtual machine Provide the name of distribution that you want and test cloud will throw SSH connection credentials back back at you Test cloud manages entire virtual machine lifecycle It supports shortcuts for most of the popular distributions namely Federa, Federa Core OS, CentOS, Ubuntu and Debian So you don't have to keep looking for URLs For Federa, it also supports fetching the latest rohite nightly image latest successful compose which might be useful for testing and and or CI integration in your projects Of course, you can use any distribution which provides q-call image with cloud in it for cloud didn't pre-installed Apart from this test cloud also has a mechanism to inject cloud in it into distributions Which don't have installed by default. This is currently a pretty Experimental feature and it's supported only on CentOS Weigrant images which come without cloud in it included test cloud does the injection by Directly typing in commands on a serial console What's inside test cloud? Test cloud is based on libvirt or specifically its Python bindings on host side and it's using cloud in it on guest side If libguestfs is used for q-call images manipulation and it will be used for distribution detection in near future too Test cloud basically connects bunch of virtualization libraries at some secret source. It's open source of course, but let's call it secret source and Around those libraries to make them more pleasant to use and Wraps it up in nice package. Thanks to using libvirt. You can also mix and match virtual machine management between test cloud and other libvirt compatible tool like weird manager or GNOME boxes as you wish What do you find to match your use case? Now it's time for a short demo so this is the most basic command you can you can use it serves as Some demonstration it creates Instance which is in test clouds terminology virtual machine of latest federal release After any Instance creation request you can see test cloud outputs Connection details connection tips so you can just copy and paste SSH connection line and Connect to the created virtual machine now we are creating Rohite instance as you can see I'm using different binary name T70 somebody might Find it easier faster to type. So it's it's there and of course test cloud supports bash completion which you can you might find useful in management of virtual machines you you have you have created with it now we can apart from standard cloud images test cloud can create a federal coro s instance This was contributed by by a lily from our team From federal QA and now as you can see test cloud is downloading an image because I haven't Created the federal coro s with this exact image from 25 25th of July So test cloud will take care of finding right URL and downloading an image Apart from specifying shortcuts for distributions and their versions You can also provide Exact URL or even local file path to an a QCOW image test cloud will either copy or create a sim link For for you, so you can save some spaces sim linking the file Created virtual machines used to layered storage. So base image isn't changed in any way and Instead instead of changing the base image test cloud is leveraging Overlay images which contain all the changed files and changes so It can grow Really fast when when you are doing something like DNA like the net update Now we can see we have created the federal coro s instance Now this is something I'll talk a little bit later. We are using femur user session this is useful mainly in constrained environments and This is something you can check out with Help page or manual page of test cloud. We can also specify memory capacity which should be granted to the virtual machine Memory allocation happens on demand, but cleaning cleaning of freed memory inside guest isn't implemented yet And we have created Ubuntu in user session As you can see you'll be able to see Whenever you try to specify an invalid release or version test cloud will Tell you what are supported releases for a specified distribution by default It's using latest when if you don't specify version and now just sneak peak on test clouds config file can Change defaults like default password default default hostname and even type in some cloud in its scripts Which isn't part of this talk? so Let's get back a bit to quemo user sessions Situation is a bit more complicated whenever you can't use quemo system session a test cloud supports quemo user sessions and In this case we can't rely on on having permissions to create the bridged connections bridged networking For dvm so test cloud is working around this by Adding two network devices to a VM one serves as a route between guest operating system and Internet and the other one is route For SSH connection test cloud creates port forwarding from from host to to guest in In such scenarios, so you will have SSH connections on different ports port para virtual machine and Thanks to this you can run test cloud basically anywhere it runs in Containers in even unprivileged containers it runs in open-shift ports, and you can even run it on your mobile phone with androids provided that you can disable selling nooks and You need to compile lib weird a bit differently than what's Without defaults for federal but what it works there so it can run anywhere anywhere in this mode and What about API? Test cloud provides Simple and as we will be able to see in a moment Python API taking just a few lines of code to create virtual machine and On the other hand the API is is a robust and you can customize any step and any Configuration or default test clouds uses to to fit your needs and apart from that as I have mentioned Before test clouds a relies on cloud in it in in the guest systems in virtual machines So you have all the possibilities of cloud in it a Specifying a bunch bunch of stuff Specifying even custom commands to be to be run custom batch scripts to be run after after a machine machine boots up Test cloud is also leveraging cloud in it and these batch scripts to work around some some around some issues in some distributions and namely Ubuntu, which isn't using Network manager, but system D network D and we have to change some default configuration around there and Apart from that doing some fixing for rel 8 cases So this is just a quick and quick look at some really basic API example In the first line, you can see we are just importing test cloud and it's it's parts test cloud is internally divided into two basic modules image and instance image serves for operations around distribution base image and overlay storage and instance serves as Object representing something some representation of an virtual machine for LibVirt On the third line, I am using test cloud Utility to get latest Ferrera Rohite image. There are functions for Ubuntu, CentOS and Debian All of them support different parameters, but there is the code of them of these functions is pretty simple and You can take a look at it and see what are supported values or Or it will throw out an error message saying what you can specify as a version On fourth line, we are creating just an image object and then preparing an image, which means it will download Qcow from remote resource or Do a sim link if it's a local path On seventh a seventh line We are creating an instance object with Instance name, which you can use anything you want or how to generate it from have it out to generate it from names of famous people and We are passing also the image object to the instance object. Then we will prepare Prepare an instance, which does a bunch of magic in background prepares XML definition of a virtual machine for LibVirt and finally it will spawn VM which will add to LibVirt and then we can start it and Finally get its IP address. If you were using user session, you would also need to get instance port To know on which port and the instance runs. Apart from start, we can we can call some usual commands like shutdown, reboot, restart You can take a look at instance object in Python for example and you'll see all the possible functions you can call colonnets or that's to be exact Some small sneak peek into test cloud roadmap Currently test cloud supports only x86 hosts and guests I'm working on changing that and I'm planning to start with 64-bit ARM and I'll continue with any more if there is demand for other architectures This will also allow to not only how test clouds to run on 64-bit ARM, but also to create guests ARM 64-bit guests on x86 hosts, so that might be another interesting use case for test cloud if you If you would need to test some different different architecture and Containers wouldn't suffice there Again architecture is a bit of a big item here. I'm planning to Refactor test cloud code a bit which got got in Rotten state since Since it's basically unchanged from Task on this where test clouds emerged and Having plug-in architecture for distribution support would make it easy for anybody to add definition for any distribution Specific you are a shortcut parsing at workarounds if such distribution would need it and Specify some other suitable defaults if they differ from test cloud defaults The third item on the list is Another refactor and and rewriting Because distribution detection is currently handled in a pretty hecky manner Which works but is far from ideal because it's based on file name matching due to missing the biggest fs bindings on pi pi and since some of our users and Community members are using test clouds from pi pi installed from pi pi environment and to the best fs isn't there I'll take a look and work on that And that's a resolved distribution detection code would get refactored to rely on far more reliable mechanism to detect distributions via libgstfs inspect If libgstfs inspects if libgstfs Python bindings are present currently test cloud would use use them to detect if You are running real 7 or or newer and if it's in a user session and in such scenario test clouds needs to Change model of a network adapter another point here is Pretty easy fix its ability to easily specify config file on per instance basis from command line interface because currently you can change Test cloud settings file and it's applied to any instance you will create from command line interface or and it's used as a default for API unless you are changing that and This will allow you to have set of configurations and Decide and use whenever whatever configuration you need or want and the the last item here is an option to expose SSH as a socket instead of IP or IP and port pair which is what test code currently does even in in the API side and Being able to use SSH socket would possibly grant you faster SSH performance and You will be able to use it in more API friendly way than having to parse SSH port and IP address I would be glad if you have any ideas or if you Hit any shoes now. I wouldn't be glad if you hit any issues But in case you do please report them on our test cloud the repository You can find it on this URL or you can ping me on email that's mentioned in the bottom of the presentation and Now it's time for your questions