 All right now, so we can start with the next presentation. We're going to look at the testing and lava. Hi, my name's Paweł Wieszodek. I work at Samsung R&D Institute Poland. I'm a member of Tizen Common, GNULINUX Distribution Release team. And since my occupation, I'm involved in lots of testing, lots of verification and validation of system images for embedded GNUX devices. Today, I would like to be your guide through a setting up of your own lava laboratory, because that's something we did to automate most of our work and to focus on much more interesting tasks that we have to do in our daily jobs. I will start with a short introduction to what lava actually is. Then I will move to the main section, which is actual setup of the laboratory. I would like to show you some tools that we used as well to simplify your work even further. Next, I will give you some hints on what can be done next. And if there's still time, we'll have a short Q&A session and some final thoughts. So what lava actually is. Lava stands for linear automated validation architecture and serves as an automation system for deploying operating system on not only embedded GNUX devices, but also any kind of emulator or virtual device. It can deploy root of us, kernel, DTB, anything that is needed to boot up your device. Once it prepares your device, it allows you to run boot, bootloader, or even system level tests on your device. But some extra hardware might be required for the full support of all lava features. And when actually does it come in handy? In the simplest use case, with just a single board, for example, big bone black, which is reference device for many open source projects, it's easy to manage just one on your desk. Also, with just a single instance, you don't have to worry about managing resources of your miniature board farms. But sooner or later, you might come across some new interesting target devices you would like to support for your open source project. For example, Arctic 10 in top left corner, or Android text U3 on the bottom. That's when things might get complicated. Adding to that, even new architecture like minibords, which run on Intel-based chip, might complicate it even further because all of these devices have to be flashed in a completely different way and support different communication ways between your test server and your actual device. What if you have to complicate things even more and have to manage a whole built farm, a whole board farm, actually, with multiple instances of each of your device? Well, that's where lava comes into place because it provides an abstraction layer for the whole board farm. This way, all the complex device management is put onto the lava itself and is no longer your own task. Also, many different devices have various capabilities. It would be much easier if you don't have to worry about finding an actual device that supports all the capabilities you need for tests. And with lava, you can only define what you need. And this way, if your board farm has a proper device, you'll get what you requested. Also, you don't have to worry about scheduling and dispatching multiple tasks on numerous devices. So if you would like to parallelize all of your tests and get your results quicker, that's what lava can provide you. And what you'll get out of the box is a unified device environment. So each developer does not see a board anymore. It's just a generic device which can be flashed with operating system image and which can get some tests to run. And all the developer sees is just a bunch of results that he gets with no worries about flashing device, about running tests on them, or how to get results back. Also, the direct connection to the devices is still available in lava. For example, we are hacking sessions or board overseer. But these topics are more complex than just setting up, which we'll be focusing on today. Lava is currently in use by multiple projects, by multiple companies. For example, by Linaro for their board farm in Cambridge, by Kernel CI for boot tests of current kernel trees, by Automotive Grade Linux and Debian as for GNU Linux distributions. So once we all realized what can we get from our own lava laboratory, let's go to the actual setup. Just for start, it's the best to focus on standalone instance with no remote workers, with no distributed environment. Standalone instance will allow to get the most of lava as quickly as possible. We'll also focus just on the virtual devices. And the tests that should be run at the beginning should be as simple as possible, just health checks if nothing else comes to you during the setup. Why is that? Mainly to reduce the complexity of the whole process. Also, it's best to familiarize with possibly new workflow of your testing automation procedures by not caring about some caveats of specific boards, but having just virtual devices. Also, it's much easier to understand lava concepts when you have the well-tested and quickly to setup environment on your hands. And lastly, although lava will allow you to reuse your current test cases, it's best to postpone the process of learning the new ways of running your tests on the lava board form. As for requirements for your own lava laboratory, the only one is to have Debian-based machine. Currently, support for Ubuntu is frozen. More details you can find in the link on the presentations. But for now, any Debian instance that you have to spare will be sufficient. Exactly, that's the host. If you'd like to run other Linux distribution on the actual device under tests, I believe currently open embedded Fedora Debian are supported out of the box. And other distributions will require a little tinkering. As for other requirements that you'll need to set it up, of course, system image for your Linux board, some health check job, which together with system image is already provided in lava by Linara. Also, device type template. And for QMU, which we'll focus today, it's already available in default lava distribution as well. And actually, the only file that you would need to set it up is device dictionary, which serves as a definition of the instance of your device. And for QMU, it's just three lines you'll see on the bottom, which only gives you an info which device template should be in use, assign MAC address, and set available memory. Thanks to the lava packages, all you have to do on your host machine is to prepare a database for the lava and let install meta package, let install lava meta package. All you'll need further is resolved automatically with dependencies. As for the common post install tasks, default Apache configuration is already available as well. And if you disable default pages and replace it with lava server configuration with enabling of two additional modules for Apache, you're all set to go as for the host configuration. Of course, you'll have to create super user for your lava laboratory. And finally, actually add the devices. Adding the devices consists of three steps. First of all, you have to add device type to your lava laboratory with the first command on the bottom part. Then you'll have to inform your lava laboratory about a new instance of your device. And finally, define all the remaining information about your virtual board instance with three-line file you saw earlier. Actually, two more things are to be done to have the whole system fully operational. You'll have to assign a worker for your device and define a health check so that lava can always verify that the device is fully operational. Once this is done, you're good to go. You may safely submit your test cases. Lava supports both CLI interface for the automation of the whole process as well as web UI for quick tests if you would like to check your new changes quickly. Having it all already set up, you might consider some tools I would like to propose to you, which may make your future deployments easier, quicker, and safer, having it all in a reproducible way. For start, I would like to show you the configuration management suite. For lava, it is equally well whichever tool you'd like. So if you prefer SaltStack, Chef, Puppet, or Ansible, it won't matter as long as you'll have a reproducible environment for all of your future deployments and the same exact configuration on both your testing environment and your production environment. So choose your personal favorite and Ansible roles should be published for setting up the fully virtual just starting lava instance in the next couple of days. As for the environment virtualization, which I believe you will be interested in having for your first lava instance, you might choose from different virtualization providers I would like to propose too, depending on how much time to have and how much flexibility do you need from the provider itself. If you need to have it set up really quickly, Vagrant would be your choice. It allows you to bring up new instances instantly and it provides you with a wide range of prebuilt machines via Atlas service. But do be careful with prebuilt images since you have no control on what actually is on the system image. If you would like to think more to adjust it to your needs, you might consider Ligvert currently maybe one of the most flexible tools for these kinds of tasks, still equipped with really user friendly both CLI and GUI tools. Once you have it all set up, you might consider your next steps and one of the possible follow-ups to setting up new lava laboratory could be adding completely new device types to lava. This time, actual devices, physical devices and all the documentation for doing so is already available. You might also be interested in writing your own test or migrating your current test cases to lava. Devote lava documentation has you covered as well. But if you'd be more interested in contributing to some other project, you might consider adding your lava instance to the Kernel CI project. You would, I believe, you would also benefit from familiarizing with both AGL test framework setup instructions and with documents that civil infrastructure platform testing initiative prepared. And if you'd prefer to watch and listen instead of reading, you might be interested in these three talks, a little more detailed introduction to Lava V2 by Bill Fletcher, or having direct access to your devices within lava laboratory instance by free electrons. You also could benefit from the next presentation that is right after this one by Jan-Simon Miller. Of course, if you would need any help, any further help, the exhaustive documentation is already available at each instance of lava laboratory. And if you'd like some direct contact, lava users show their questions on mailing list, either on mailing list or on linaro-lava.irc channel on free note. To sum it all up, I hope that I showed you that initial setup of lava laboratory is pretty easy, thanks to already in place package repositories for Debian platform. And that setup is instant once you know what to expect and what do you have to prepare before. Also, environment unification for various device types is something that you might benefit from in your automated testing process. And with lava, you get a test execution with no cost, and you don't have to manage all of the devices by yourself. Also, developers do not have to worry about managing devices all by themselves. This responsibility can be moved to the lava laboratory operators. And as for the final thoughts I would like to show you is that although it might seem intimidating at first, with such an exhaustive documentation as lava has, it actually has no downsides. When you get through it or you have someone who got through it earlier and shares just a quick start, you get everything you need. Also, there is absolutely no need to reinvent the wheel with modern testing laboratory management software. It's already there just waiting for you to use it. And although the initial cost might be high if you're not familiar with all these tools, the full automation always pays off in a long term. If you have some questions, I would be more than happy to answer them, since we've got still a few minutes. Yeah. Hi. So it's great that you're on. Yeah, sure. So good job. Thank you for a great presentation, and giving you a good introduction. It's better than we've done so far. There's another set of sessions planned next month. We're doing the next Lenora Connect event in Invection. And we'll be doing a lot of users forum and the movie videos. And if you're interested in lava, please, either come along. That might be difficult, but I will definitely pick up videos afterwards. And we'll be, of course, ready to answer questions. Suppose that you have two boards of Ceylon together, like a motherboard and a trial board. Each have an independent shell, and you want to write a disk that does some action on the one on the motherboard and another one on the trial board, and then see that things are fine. Is that possible in lava? I believe so, but I have not experienced user enough to answer your question fully. I believe that you would have to add two different devices. And if the child one has direct access, that there would be no trouble in that. And if it has not, so maybe some tunneling through the parent device will be required as well. If there is no more question, thank you for your attention.