 So, hello everybody, my name is Kozmin, I'm one of the co-founders of the RoPyton, the biggest Python community in Romania and I'm doing this with a lot of cool guys which are present in this room right here. Also in my full working time I'm working for cloud-based solutions and I'm a cloud engineer there working on a product. So today I'm going to talk about Argus, the omission CI, I'm calling like this because he knows everything and he's present everywhere when we're doing tests. Just before I'll talk about Argus, we need to know something about the clouds and the cloud initialization services. Also I'll talk about the components of Argus, the most important thing of it, the configuration file in which the actual tests relies on and how to use it and also creating a test. So what are clouds by IT meaning? Simply put, the clouds are some places overhose under a network in which data is processed, stored and saved by the user rather than using your local computer and such clouds came across tech as a platform as a service, infrastructure as a service and software as a service but we will focus on infrastructure as a service and there are many popular infrastructures like OpenStack, OpenMabula, CloudStack, if you don't know OpenStack is the biggest project, open source project in the world mostly written in Python. So what we are doing with these clouds? We mainly create instances, VM, virtual machines like you used to create, I don't know, a virtual box or VMWare and they are virtualized by your local hypervisor installed there. Most important things about clouds is when we're creating these instances, we also need to initialize them, to configure them. So these make the metadata providers to be very important and to know them and how particular aspects of the instance which should be configured are served. So a solution to this are the cloud initialization services, cloud init which is developed by Canonical and OpenSource, it's working very fine but some guy came across with a new idea for creating cloud initialization services for Windows and many other platforms will be supported in the future. So he came with cloud based init which is mainly used to initialize Windows machines. So this is how it looks like, it came in the shape of installer, it runs as a service, it installs with various options, it's designed for the anti-systems Windows, it's open source and written in Python and supports many popular clouds. By supporting many popular clouds I mean he knows about most of the metadata providers and it's also independent of the hypervisor, of the method which the instance is virtualized because the service itself doesn't have nothing to do with the infrastructure, it only installs on the instance and configures it and just like that. And now our son talks about merging the cloud based init project with the cloud init and we're talking with the guys from Canonical to do that faster. So this is how it runs, it's normal services and after it runs it detects the metadata provider and using that service, that loaded service, it's using some plugins to configure the instance because this is the most important thing. Like cloud's name, networking, local scripts, it can execute scripts on that machine. Also store SSH publicies and it also relies on a configuration file which looks like this. You can specify a username, groups, where to store logs, which metadata services you want to use in particular and also the plugins. If you don't specify them, all of them will get executed. So enough with that, this talk is about August. We need somehow to test it. So at first the init testing and other gates like PEP8, Flake8 are not enough just to test the project itself. We need to do some kind of integration test to actually test how it works and if it does what it really should do. So we've done some manual testing under VM instances directly on your host or through grass or even through infrastructures like I said earlier, like OpenEbula, CloudStack and mainly OpenStack. So we need somehow to automate these things. This is just a horizon interface and on the right is a VNC console, so the testing part was pretty hard. We can also use an RDP. So we've came with August. August is a beautiful open source project conceived and designed by Claudio Popa, which is core maintainer at Pylint and also the only maintainer. So through this project we are creating integration tests not only for the cloud based init project, we can create tests for everything we want to test it because it supports any kind of testing concept. It just creates a virtual machine and from there you can do everything you want by writing some code in the project and bundle all the aspects you've been doing there in a configuration file for August. So it's written in Python, it uses Tempest to create the instance itself. This is another project by the OpenStack community which tests the OpenStack infrastructure and how the instances respond and if everything works as it should. So it's scenario based and it gives unit tests like reports. Like you're seeing in the right, there are some failures, tracebacks and like unit test shows you when you run a test, it gives you the number of failures which tests have run and in what time. So August, to understand August we need to first understand its components. So it's created of scenarios and those scenarios are encapsulated, are bundled together, the recipe, tests, introspection module and also the runner which runs everything above and the most important thing, the configuration file in which you create these kind of scenarios. I will show you in detail what are these. So this all is looking a scenario, it's just some base code and abstract methods and there. You don't have to customize these objects, you can use the already created one or if you want to do different things, you can inherit from there and create your custom things. This is August's recipe, the introspection module which gathers the details from the instance and the actual test which are run not over the instance but in your local computer. So how these are working together is the scenario which encapsulates the recipe, the recipe configures the instance after it's created by the scenario then using the introspection module you gather details from the instance and comparing with the expected ones. So the tests are getting executed and you get failures for success. Configuration file, here we can have basic settings like credentials, details about the image, the flavor of it, details in particular for the project you test. Cloud-based in it for example, a basic scenario which bundles everything and you can inherit from there and create your own scenarios with your own tests, you can customize all the other things like the recipe use or the introspection module if you don't like the default one. This file looks, this is just a sneak peek from the configuration file. Above we define image you must use because to install, to create a virtual machine through that infrastructure you also need to provide an image and that image you deploy through glance and open stack and after that the infrastructures with the infrastructure you can see it's a reference ID and put it there and this is how you tell Argus to use that image when creating the instance. And below is the basic type of scenario in which you gather the things you want to use. And from that basic scenario you can create custom scenarios with your own recipes, introspection or even images and other settings. Also you can customize the instances you create by providing metadata to the instance which is passed through Tempest. Also custom user data, through Argus you can also create environments. Because you want to customize the environment before creating an instance, for example like modifying a configuration file. A solution to that is to stop the services and configure the configuration file of a component from the open stack ecosystem for example NovaConf and after you write your desired details you restart the services and run Argus as normal. So Argus supports this kind of things through environments which can be specified in that configuration file. You don't have to do these things manually, Argus will do those automatically. Another cool thing about Argus is that you can mimic different infrastructures. So you can make cloud internalization services which run on an instance to think that it runs on a different infrastructure like cloud stack or open ebola or everything you support. And you can do that by creating custom web servers through Argus and do additional changes to the scenario and the recipe in a way to make the cloud internalization services when it runs to use that particular services. And when it uses that service it just thinks that it runs on a different infrastructure by seeing that new metadata provider is available other than the open stack. Also you can attach a drive with a shell on it named context.sh for example and when it finds that file it thinks that it runs under open ebola even if it runs on open stack. So this way you can test different structures which is a cool thing in Argus. This is how we use it, there are a lot of options. We mainly focus on the cloud because most of the time we are testing cloud based in it but with Argus you can test everything you want. As unit test has a fail fast option to fail at the first encounter error you can pass the most important thing for it, the configuration file, you can put a pause before the test will begin. Also you can test various operating system types or scenarios types when you define that configuration file you also specify a type. Another important thing you can specify an output directory. This is very important because most of the things that are run on the instance are also making some logs and those logs need somehow to be retrieved. Because after they are retrieved you check those logs and this way you make sure that everything runs smooth on that instance. You can also test custom builds and custom architectures. Another important thing is that you can modify the actual installer by providing an archive with different files, binary files. Cloud based in it was using Python on the x86 architecture and I wanted to test that on x64 so I built a custom installer which I passed it through the patch install command so I test this way, I test the x64 too. And with git command you can test patches which are not integrated because this is the main reason we are using Argus to test cloud based in it. Just to make sure the patch really does what it should do and below it is a real life example with Argus I test cloud based in it with the argus.conf configuration file I put a pause on it if I want to manually intervene on that instance. I specified the output, a directory named cblogs and the architecture x64 and the most important thing the git command which specifies the git fetch and checkout commands retrieved from the review.uponstack.org site. So this way we can test a particular patch. So how you develop a test? Wherever you have a patch or not for cloud based in it and if you want to test something you can just use those available by default scenarios, recipes, tests or introspection modules but you can create, you could also create custom ones. You gather all these things together in a scenario underscore and whatever you like name group in the configuration file and there you put all these things. So then you run Argus with that configuration file and when it came it come across that particular group it just create a new instance using the specified scenario then it configures the instance with your recipe or the default one then it runs the actual test using the introspection module to retrieve details from the instance and comparing the expected ones just to make sure that what you expect is the same, not giving favors, everything is perfect. So thanks, this was a quick talk. I'm not usually put on the last slide many other links because people don't click them but below is the Argus project, it's open source, it's on GitHub and above are other details about the project we test cloud based in it and that's all questions. So no questions, all right?