Argus - the omniscient CI
Poieana, Cosmin
Cosmin Poieana - Argus - the omniscient CI Bring the continuous integration to a new level, through a platform/project independent framework able to give you unittest-like reports. Argus is a scenario-based application written in Python, driven by custom recipes under configurable environments, that can be used for testing a wide variety of small and big projects, with the ability of querying live data from the in-test application. Until now, it's successfully used with [cloudbase-init] (a robust cloud initialization service for instances) under OpenStack and not only, due to its extensiveness and the ability to mimic different infrastructures. The goals of this talk are to show its generic scalability, how simple is to create such kind of recipes, the relationship between scenarios, introspection and tests and, but not last, the unlimited freedom of creating very custom aspects of these entities which lead to relevant and in-depth ready for analysis logs. There are no major prerequisites to understand it, just to be familiar with Python and optionally have a focus on cloud infrastructures.
 So, hello everybody. My name is Kozmin. I'm one of the co-founders of the RO Python, 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 is present everywhere when we're doing tests. Just before I talk about Argus, we need to know something about the Clouds and the Cloud Inutilization 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 served by the user rather than using your local computer. And such Clouds came across tact as 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, OpenMebula, 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, virtual box or VMware, and they are put to life 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, is working very fine, but some guy came across with a new idea for creating Cloud Insighted 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, runs as a service, it installs with various options. It's designed for the anti-systems Windows, is 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 infrastructure. It only installs on the instance and configures it, just like that. And now, some 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 Clouds 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 an 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 Argus. 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 Gress, or even through infrastructures like I've said earlier, like OpenEBula, Cloud Stack, 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 Argus. Argus is a beautiful open source project conceived and designed by Claudio Poppa, which is core maintainer at Pylint, but 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 our configuration file for Argus. So, it's written in Python. It uses Tempest to create the instance itself. Tempest 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 tests shows you when you run a test, it gives you the number of failures which tests have run and in what time. So, Argus, to understand Argus, we need first to... To understand it, we need to first understand its components. So, it's created of scenarios. 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. 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 how it looks. It all looks a 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. The 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 is all 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, that infrastructure also need to provide an image. That image you deploy through glance and open stack. After that, the infrastructure, you can see it's a reference ID and put it there. This is how you tell Argus to use that image when creating the instance. Below is the basic type of scenario in which you gather the things you want to use. From that basic scenario, you can create custom scenarios with your own recipes, introspection, 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. Suppose 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. After you write your desired details, you restart the services and run Argus as normal. Argus supports these kinds of things through environments which can be specified in that configuration file. Argus will do those automatically. Another cool thing about Argus is that you can mimic different infrastructures. 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 eBula or everything to support. 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, you can use that particular services. 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. When it finds that file, it thinks that it runs under open eBula even if it runs on open stack. 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 on the instance are also making some logs. 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 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. 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. Below 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 specify the output, a directory named cblogs and the architecture x64. The most important thing is the git command which specifies the git patch and check out commands retrieved from the review.apponstack.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, RISP test or introspection modules, but 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 for not giving favors. So I think it's 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. So we have Argus GitHub and above are other details about the project we test cloud based in it. And that's all questions. No questions. All right.
 So, hello everybody.  My name is Kozmin.  I'm one of the co-founders of the RO Python, 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 is present everywhere when we're doing tests.  Just before I talk about Argus, we need to know something about the Clouds and the Cloud Inutilization 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 served by the user rather than using your local computer.  And such Clouds came across tact as 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, OpenMebula, 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, virtual box or VMware,  and they are put to life 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, is working very fine, but some guy came across with a new idea for creating Cloud Insighted 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, runs as a service, it installs with various options.  It's designed for the anti-systems Windows, is 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 infrastructure.  It only installs on the instance and configures it, just like that.  And now, some 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 Clouds 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 an 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 Argus. 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 Gress,  or even through infrastructures like I've said earlier, like OpenEBula, Cloud Stack, 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 Argus. Argus is a beautiful open source project conceived and designed by Claudio Poppa,  which is core maintainer at Pylint, but 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 our configuration file for Argus.  So, it's written in Python.  It uses Tempest to create the instance itself.  Tempest 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 tests shows you when you run a test,  it gives you the number of failures which tests have run and in what time.  So, Argus, to understand Argus, we need first to...  To understand it, we need to first understand its components.  So, it's created of scenarios.  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.  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 how it looks.  It all looks a 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.  The 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 is all 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,  that infrastructure also need to provide an image.  That image you deploy through glance and open stack.  After that, the infrastructure, you can see it's a reference ID and put it there.  This is how you tell Argus to use that image when creating the instance.  Below is the basic type of scenario in which you gather the things you want to use.  From that basic scenario, you can create custom scenarios with your own recipes, introspection, 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.  Suppose 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.  After you write your desired details, you restart the services and run Argus as normal.  Argus supports these kinds of things through environments which can be specified in that configuration file.  Argus will do those automatically.  Another cool thing about Argus is that you can mimic different infrastructures.  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 eBula or everything to support.  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, you can use that particular services.  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.  When it finds that file, it thinks that it runs under open eBula even if it runs on open stack.  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 on the instance are also making some logs.  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 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.  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.  Below 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 specify the output, a directory named cblogs and the architecture x64.  The most important thing is the git command which specifies the git patch and check out commands retrieved from the review.apponstack.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,  RISP test or introspection modules, but 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 for not giving favors.  So I think it's 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.  So we have Argus GitHub and above are other details about the project we test cloud based in it.  And that's all questions.  No questions. All right.
Cosmin_Poieana_-_Argus_-_the_omniscient_CI_0_59.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_60_107.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_108_503.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_504_1535.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_1536_1631.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_1632_1751.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_1752_1967.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_1968_2339.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_2340_2591.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_2592_2891.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_2892_3971.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_3972_4235.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_4236_4571.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_4572_4739.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_4740_4931.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_4932_5519.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_5520_6179.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_6180_8831.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_8832_9095.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_9096_10499.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_10500_11699.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_11700_11819.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_11820_12611.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_12612_13319.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_13320_13439.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_13440_13583.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_13584_13763.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_13764_28283.png Cosmin_Poieana_-_Argus_-_the_omniscient_CI_28284_28512.png
So, hello everybody. My name is Kozmin. I'm one of the co-founders of the RO Python, 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 is present everywhere when we're doing tests. Just before I talk about Argus, we need to know something about the Clouds and the Cloud Inutilization 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 served by the user rather than using your local computer. And such Clouds came across tact as 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, OpenMebula, 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, virtual box or VMware, and they are put to life 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, is working very fine, but some guy came across with a new idea for creating Cloud Insighted 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, runs as a service, it installs with various options. It's designed for the anti-systems Windows, is 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 infrastructure. It only installs on the instance and configures it, just like that. And now, some 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 Clouds 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 an 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 Argus. 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 Gress, or even through infrastructures like I've said earlier, like OpenEBula, Cloud Stack, 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 Argus. Argus is a beautiful open source project conceived and designed by Claudio Poppa, which is core maintainer at Pylint, but 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 our configuration file for Argus. So, it's written in Python. It uses Tempest to create the instance itself. Tempest 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 tests shows you when you run a test, it gives you the number of failures which tests have run and in what time. So, Argus, to understand Argus, we need first to... To understand it, we need to first understand its components. So, it's created of scenarios. 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. 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 how it looks. It all looks a 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. The 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 is all 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, that infrastructure also need to provide an image. That image you deploy through glance and open stack. After that, the infrastructure, you can see it's a reference ID and put it there. This is how you tell Argus to use that image when creating the instance. Below is the basic type of scenario in which you gather the things you want to use. From that basic scenario, you can create custom scenarios with your own recipes, introspection, 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. Suppose 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. After you write your desired details, you restart the services and run Argus as normal. Argus supports these kinds of things through environments which can be specified in that configuration file. Argus will do those automatically. Another cool thing about Argus is that you can mimic different infrastructures. 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 eBula or everything to support. 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, you can use that particular services. 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. When it finds that file, it thinks that it runs under open eBula even if it runs on open stack. 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 on the instance are also making some logs. 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 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. 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. Below 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 specify the output, a directory named cblogs and the architecture x64. The most important thing is the git command which specifies the git patch and check out commands retrieved from the review.apponstack.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, RISP test or introspection modules, but 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 for not giving favors. So I think it's 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. So we have Argus GitHub and above are other details about the project we test cloud based in it. And that's all questions. No questions. All right.
today I'm going to talk about Argus, the omission overhose under a network in which data is service. But we will focus on infrastructure as a instances, VM, virtual machines like you used to So, these make the metadata providers to be very aspects of the instance which should be with a new idea for creating Cloud Insighted independent of the hypervisor, of the method also the only maintainer. So, through this project, we are creating integration tests, not for Argus. So, it's written in Python. It uses tests the OpenStack infrastructure and how the run and in what time. So, Argus, to understand you create these kind of scenarios. I will show 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 custom scenarios with your own recipes, by providing metadata to the instance which is Through Argus, you can also create environments. thing about Argus is that you can mimic different infrastructures. You can make cloud service, it just thinks that it runs on a below is the Argus project. So we have Argus