 Good morning, yep ok So we'll talk about building a board of firm for continuous integration and our main point is to show you how to do it For me for example integration into canal CI or to be able to use it for other purposes So we'll show you mainly what is a continuous integration on which part you have to do if you want to build a firm of board In your own company or at home Ok, so let us present ourselves first Quentin Yeah, so hi everyone, I'm Quentin. I've done my end-of-studies internship at Fréélectron and I've joined them in September, so now I'm an engineer at Fréélectron So basically my internship subject was the subject of the talk, so I can Legitimately talk about that. So I'll let Antoine continue with the slides So as he said we work at Fréélectron, we are a company based in France, and well just a few words about it We are providing services for embedded Linux So SOC support drivers, and we are also doing trainings in the same area So in embedded Linux or some of the tools that are related to it like Yocto or Bedouin We both live in Toulouse, which is in the south-west of France I am also working at Fréélectron, of course, I was involved into the same project, but Quentin did most of the work I just had a look Well, from a far point of view, but well, I Know what was going on still So This is the contents we will talk about. First we'll have an introduction on what is Continuous integration, so just to have in mind, to have a clear view of what we're talking about Then we'll see the component of a continuous integration on which one of them we'll have to build To have a firm of board in our company And then we'll dive into the main subject, which is what we did at Fréélectron, to have a farm of board To be integrated into CanalCI, but also to be used for other purposes And we'll show you one of them, which is a tool we built on top of it to control the board remotely Ok So introduction, just to have the same view of what is a continuous integration So it's a software engineering practice in which we will test changes Immediately after we made them to be sure it's not breaking the project Basically when you have a large project, you may have, you may work on a small part, which can impact many other uses of it But you are not able to test it, so continuous integration will help you to test it on many Different use cases, with different configuration, and in our case, for many board So the goal of this is to catch bugs or regression early, to be able to fix it before we make a new release of our project So in continuous integration, you have three main components, we will have a clear look at it during the next slides To just understand what are these components, but basically you will have continuous builds, a test automation part and then processing of the results So why do we need it, when speaking of the Linux community We have a lot of different platforms supported by the Linux kernel, and this is especially true for ARM Because we have many, many associates that can share some IPs So if I make a change in one driver, that can impact some other platform And I may not be able to test it on the other platforms So this is why it's really hard to test it in our community So having continuous integration can really help to find bugs early, or to find regression early To be able to fix it and not break other platforms Also we are in a community very active, so we have a lot of changes We have a new Linux release every two months, and in each release we have thousands and thousands of changes So that means we can have also lots of bugs in it This is not a problem, but we just have to detect them There are other projects that aim to detect regression or bug early, like Intel Zero Day But this was mainly done for x86 platforms, so it's really useful but not really for ARM Intel Zero Day was not able to boot a lot of kernels on ARM boards So this is why we also needed something specific for ARM So we needed it as a community for Linux, but then at the company you also needed it So why do we need it at Free Electrons? We contribute to a lot of ARM platforms upstream So this means we can be impacted by lots of bugs And we also have a lot of different boards that maybe nobody else have So it can be really good to allow the community to be able to test regression on these boards We also cooperate with some ARM vendors, so it can be good for business to catch bugs early To just ensure that the mainline kernel is still working for these processors And we also have ARM maintainers for ARM 64 So it can be also useful in this position to catch bugs early And finally, we try to keep track of the modification of the platform we maintain To be able to just know it just work So this was the generic part about what is the continuation integration and why do we need it Now I will dive into what are the components of the continuous integration To really understand what we're talking about But it's not yet specific to kernel CI It can be applied to any continuous integration implementation So we find, again, the three parts I was talking about Which is the continuous build, the test automation and the processing of the result of the test So basically the first part will be responsible to track for changes in our project So there are many ways to track them We will show you who it's done with kernel CI And then when a change is detected in our project We can trigger some builds to build actual images to be able to test it And then this build will be tested by the test automation part Which will be actually our farm off-board So when we're speaking about our farm off-board At free entrance, we implemented this part So the test automation part Once you launched your test, you want to gather the results To be able to know if there was or were any bugs or regression on it And so this is the processing part So you need to gather other results to be able to detect if it was a regression or a bug or something normal So this was the generic part about how you build a continuous integration process But then we will have a look at what kernel CI is doing Because we did a border farm Which is not only used in kernel CI but which is also used in kernel CI So it's really good to understand how kernel CI is working To be able to add a new farm off-board into kernel CI So let's first present what is kernel CI Kernel CI is responsible of the continuous build part And the processing part of the results But not about the test automation part So if you want to be able to integrate a farm off-board into kernel CI You need to implement this part But you don't need to do this one or this one It's already done for you And that makes the thing really easy to do Kernel CI, so it's a project which was started I guess three years ago Yes, two years ago You can find main information on the website And you can also see all the results of all the tested Which were made by Kernel CI on this website The aim of this project is to detect regression before the rich users So we try to detect early regression by testing every day Every hour for new changes to be able to catch them For example, per day there is more than 2,000 boot tests On more than 200 unique boards So the first part of it is to track for new changes There are many ways to do it In kernel CI, it's tracking git repositories Every hour to detect new changes And the way it's doing it is it will download the latest version of a given repository Each hour and see if new commits were pushed to it If there are new commits in this repository This will trigger a new build to be able to test these new modifications In kernel CI, it will track more than 20 git repositories So there is a well-known Linux tree And then you also have ARM SoC, Linux Next, Linux Table For example, Netnext, but also other branches This is good because it allows you to track for regression Into the official git tree of the kernel, which is a Linux one But also for changes that will be integrated into this tree Before it's pulled on merge into this tree So for example, if you track for regression into ARM SoC Then you will be able to detect bugs into ARM SoC Before it reaches the Linux tree So once a changes was detected into a given repository That is tracked by kernel CI A build is triggered And basically it will build all depth configs for ARM ARM 64 and some for X86 And of course there are associated device trees If any to be able to actually test these images on the board MIPS 2? Ok, so MIPS 2 now This is good And this is the interesting part If you happen to have a lab in your company This is when you join the game SoC kernel CI will track for new changes It will trigger a build to build a kernel With these new changes inside it To be able to test it And then it will send these images And the test to do with these images to the labs So for example to the labs at free electrons And well this part will be responsible to test it And to actually test it And then once it's done Kernel CI will gather the results To be able to detect new failures Or new regressions So we had a view of what kernel CI is doing If you just go back one slide And we know now that this part And this part is already done So you don't have to do anything If you want to be part of it But you will need to be able to build a firm Which is the test automation part And this is what we are going to talk about now So the test automation will be the part responsible To control the board To launch test on the board And also to gather the results from the board Ok, not to gather the entire results Of all the test because this will be kernel CI jobs But to gather a particular test on a given board And this part will be the firm of board Ok, so you will be able to have one component Which will control all of your board In your company to do these things So this implies many things to implement But Quentin will talk about this One thing to notice in kernel CI Is it's compatible with one particular software Which was developed by Linaro And called Lava So if you want to do the test automation part For kernel CI Then you most likely will need to install Lava To control your board Ok, so now I will talk about Lava then Because it's the missing part for the automation Lava is a self-hosted software Which aims to control boards So it uses external tools So basically you tell him You should use this software to power on or off a board And also how to get to serial So Lava is working with Certunet or Conmex And for the board control You can use PDU daemon Which is developed also by Linaro Or you can use your own custom software It also automates boot Bootloader user space testing So that implies tests So you have to tell him what to test How to test it And which images to test So as Antoine said Connexia is sending tests So it just tells you where to find the images So the images are built And you will have to download it It's just Lava work to do So you can basically do anything you want In Lava So for example Connexia is testing the user space What you could also test How the bootloader is working The environment via variable in it Basically the tests are called jobs So it's important if you look at the Lava documentation It runs tests simultaneously on all boards So you don't have to wait To have finished to test the next one It also provides API for full automation Well, you need it Because otherwise Connexia wouldn't work with it So basically if you don't want to work with Connexia That's a shame but you can do it So basically you can hook it with a git hook Or something like that Or your own Jenkins instance to test it Lava is also validating tests So that's how they know If a board is failing the boot job Or not So that's what Connexia is gathering So you can check the wiki at wiki.linaro.org So that will help you I guess So, next So as I said Lava is a self-assisted software It's organized in a master dispatchers fashion So, what does that mean? That means that only one master is working with several dispatchers So the master is controlling the farm Connexia will just send jobs to the master of Lava So the master is handling the API And receive the test to run It will also schedule the test to run So as I said it's working with dispatchers So it will receive the test And then find the dispatcher to which it should send the test So the given dispatchers will handle a set of boards So each dispatcher has unique boards So you don't have to care about that So a board will be only in one dispatcher So every dispatcher has the configuration of each board It owns And it's physically connected to the board So that means that if a board is connected to a dispatcher This dispatcher should be able to control the power and the serial I mean, in our case that's not really important Because the master and the only dispatcher we have Is on the same machine We'll have everything on the same computer Ok, he tricked me on this one So, what is... How does Lava work? Internally, I mean So as I said You have to control the power So that's done with a PDU diamond So on top with power relays I will just demonstrate a show later And for the serial It will just redirect the output to a hotel net Instance with a serotonet And you will be able to get files on the board with GFTP So, for that You need, as I said, a configuration file So Lava is just working with configuration file Well, an important thing Ah, well, I will just say that later No, sorry The configuration file will have everything for each board So, in one configuration file for one device We'll have how to power it How to connect to the serial and where to find it An important note There is two versions of Lava So v1 and v2 in the documentation we'll see The v1 is working with configuration file The v2 is working with API You will not have any configuration file on the machine But the v2 of Lava is working Is getting tests in YAML Templates files While the v1 is working with JSON And, as I said, it's only doing with the JSON test now So, we still need to be on the v1 Which will be maintained for at least a year or two And then, fortunately, we will have to migrate to the next one So, it's important to know that devices So, boards are split into two different categories So, you have the device type and a device So, the device configuration file Is the configuration file used to tell where to find the serial So, on the last line, so connection command How to power it off or on So, hard reset command and power of command Basically, it's just for power off And hard reset command is only calling an external tool So, you can just put whatever shell commands you want So, here we have PDU client Which is a part of PDU daim And then on top, you have device type So, that's... I will just introduce the next slide Device type is a set of the same devices So, for example, say, we have a chip We have 10 chips So, you will have 10 device configuration files To say where I should find the serial of which board And then, you will have a common device type configuration That's all the commands you will have To execute in the bootloader So, everything is automated You just have to set the right command in the bootloader So, for example, you have Z-load addresses Which are the RAM addresses for the kernel address The kernel, sorry Then the root FS, you need the RAM FS and then the DTB And a lot of variables are filled in via lava Automatically, so, for example, kernel address, RAM disk address Everything So, basically, that's everything here is shared between all chips So, yeah, I think that's it for configuration files How tests run in lava now So, as I said That's ready Lava is not autonomous You have to use its API to achieve full automation So, for example, with git hooks, with changing instance Or, for example, to be a part of kernel CL Labs So, the user part is our job Or kernel CL jobs or your git hooks job This user will send jobs So, a set of kernel, DTB, and each RAM FS To run on a device type 1 It will just send that to a lava server A master And so, the server will receive the test job It will ask the dispatchers So, all the available dispatchers If they have a device available for, of type Sorry If they have a device of device type 1, for example Is available Or, if not, then it choose the jobs And will ask later for a device An available devices And if it is available If there is an available device It will just send jobs to the dispatcher In charge of this device So, the dispatcher will download everything from remote So, for example, in kernel CI storage It will apply the modification So, for all boards, you will only have I don't know, U image support So, with boot M You need the U boot header for the The NITRA-MFS And then it will start recording Entering the boot loader, executing all the commands And it will power on the board And, yeah, run the test The recording And sends record to server All the server will get the records from lava And everything is stored, of course, in the lava server So, it's permanent So, I think it's everything for lava So, next slide A bit more interesting So, it's the hardware How do we actually build the farm The previous part was mainly configuration So, yeah Just explain how it works But it's really development I didn't invent anything So, that's now part of the hardware So, I will just present the hardware So, as I said, you have to control the power So, that was the hardest part, I think So, for supply control, you have three choices So, PDU So, for distribution unit It's often rockable So, you can put it in a server rock It's really expensive 500 euros, at least We will watch it for a lab And, so, no, not really And, it's also using cathode calls, I would say So, the sockets So, you will have to buy adapters for your chargers Not really a good idea Then, you have on the right The network control multi-sockets So, the problem with that one is Well, later, I will explain We chose to have 8 boards per Whatever, drawers So, we need a poor supply with 8 sockets And, the main problem was that This network control multi-sockets Has an 8 socket version Only on the US sockets And, we are living in Europe So, we will need a lot of adapters So, then we have the last option Remotely controlled relays For that, we have Ethernet controlled USB controlled Wi-Fi controlled Bluetooth controlled Everything controlled, basically So, it's relays And, yeah, it's just wires So, you cut your chargers, you put in it And, yeah, it works So, obviously, we chose the last one Well, it's really cheap So, for example, the PU said it was At least 500 euros On the right, it was at least 120 dollars And, this one is I would say 80 pounds So, yeah, 90 euros Yeah, we have a lot of ports So, basically, this model is an 8 port relay But you have also a 2, 4, 8, 16 and 32 version So, yeah, you can basically do anything you want It's really small, so you can see Comparatively to the Ethernet port And, we chose the TCP one Because we have already a lot of USB hubs So, yeah, I don't want another USB Controlled device And, they support virtually any power supply As I said, you just have to cut the charger And put the wires in it So, that's really more interesting Than the two different choices That are present in the area So, now, I know how to control the power supply But how does really the power supply work? I mean, it was easy to say I'll cut the wire and I'll put in it But then I will have to throw out A lot of chargers for that That's really a good idea So, to think of a better idea We had to identify the several devices We have in the farm So, in the world I mean, it's basically all the boards Are in either of the three categories So, you have a 5V board The 12V board And the full ATX board So, yeah, embedded, but not really We separate those in two kinds So, the non-ATX supplied boards So, the 5V and 12V And the ATX supplied boards So, basically, the one in the two kinds of boards Shares the same way of being supplied So, next one Non-ATX supplied board, sorry We need two different input voltages So, 5V or 12V So, two choices Either I find a charger We can output both at the same time Or I will have to have one per supply per voltage So, one for 5V and one for 12V And it has to have enough amperage Why? Because I would like to avoid having Eight chargers per charge I will show you later So, to gain space on the farm I would say we just have one charger For all the boards on the same drawers And just split the output So, that's why we need enough amperage For example, if you have 8 boards on 5V You will need at least, I would say, 10 amperes To pour everything And for example, if we need to test later Not yet, but later, hard disk Yeah, hard disk drive You will need a lot of amperage at the start Of the hard disk drive So, basically, it shows to have one per supply For all voltages And the only charger, I would say Which is doing that, is at the export supplies So, yeah, next slide, please I don't know if you knew, but at the export supply I would put a lot of different voltages Of the 3.3V, 5V, 12V, minus 12V And a continuous 5V output So, we can just pick anything on the output And split it So, now, I'm happy I have only one charger per drawer So, I will just cut the output Of the at the export supply And then split it in different relays And pour all the boards And to protect that Because, you know, at the export supply It's not really... Everything is un realable So, I add a TV STO So, the principle is to explode If there is only any overvoltage So, I will just secure a bit the system So, the at the export supply Is what you have in your computer And your computer is not always poured on And this is the reason It waits for a signal So, when you push the button on your laptop Or on your computer On PS on, so it's the one on the fourth on the right Or it waits for PS on to be put to the ground And then it will pour off... For on, sorry So, it will be great If we had the pours supply to be always on For the non at the export supply Because you don't have to push a button or anything So, we just shortcut this one For non at the export supply boards But for at the export supply board You need anything else Because they have a pours supply We have a pours supply for each board So, you have the full socket This one put on the board And then you will have to manually push the button To start the board It's not really what automation is So, we had to cut this green wire And put it in a relay So, that's how we control the pours supply For at the export supply boards I think that's all, yeah So, now, we know how to control the pours supply of boards But now, we should get the serial of the board I mean, if we don't have that We can't have automation So, basically all the boards are working with a USB 2.0 Whatever So, TTL, DNF, DN9 Or, I don't know, a lot of USB cable So, lots of USB hubs So, yeah That was really hard to find 10 ports USB hub Which was reliable And we have to be sure Also, it's externally powered So, it's not relying on USB power Because some boards on the serial port They just throw currents So, if they all draw currents at the same time Then your USB hub just shut down So, you lose the serial connection So, yeah, that's it for the serial connection And then we have to get files on the board So, on the bootloader So, the bootloader, as you know Mainly support Two different types So, either fastboot or TFTP protocols Yes And so, TFTP protocol is way more Used And so, we needed a lot of switches And internet cables So, it was free You will see then the pictures It's really a lot of cables And which was also gigabit switches So, if later we want to test The bandwidth between two devices We can do it up to a gigabyte So, now with the actual building of the board farm So, we had some requirements We have only a limited space at the office So, a specific location It was really a requirement to be harmless to board So, what does that mean? You don't want to have a shelf with a metal thing So, you just shortcut every board you have So, we went with wood But also, you have to maintain the board At the same place Because some boards are really tiny Like the chip, so it's this big And, as you know, the internet cables are really rigid So, it would just go wherever you want So, we went with a scratch So, you just have to scratch the board And we just stay in place We wanted something easy to use So, for our use case We just want sometimes to pick a board From the lab So, if everything is fixed Then you have to put your arms behind every board That's not really easy to do So, that's why we went with drawers So, it's also allowing evolution So, if a day you want to add a board Or add a drawer, you can And we want it as many boards as possible So, we established There can be eight small boards We call it board drawers Or four big boards So, the boards board with full-attacks for supply So, now, we divided this In two different kinds of drawers The small drawers and the big drawers Small drawers Drawers with non-attacks for supply Boards So, basically, we put in one I think it's 70 per 95 cm Drawers 10 ports USB hub Which is linked to the server Then we have two 8-port switches To get files in the bookloader of each board The ethics port supply Which has its both voltage input Put into 8 ports of the relay Which is linked to the port switches To the internet switches So, it can be controlled by the server And then you just have all the internet cables In the middle And you just put wherever you can So, it's just really... It depends on how the... Well, the size of your devices So, that's how it looks like That's the last version That's a lot of cable So, you have everything on the middle The serial, the internet cable So, on top, you can really see it On the right, you have the ethics port supply Then the relay with all the... Domino's, I think, that's called And then the 8-port switches And then 10 USB ports Yeah, you could spare some place With the shorter cables That's ongoing development, I would say Ongoing work So, that's it for the small drawers Big drawers, so drawers of boards With full ethics supply So, each board has its own ethics port supply So, that's a scheme Because every board has a different size So, basically, it's not really different here So, the next one is the picture in real life So, on the right, you have the first ethics port supply With the board Yeah, it really depends The organisation of the drawers Depends on the size and model of the boards But now, here, we have four boards That's the maximum we can put Another one in this So, that's full ethics port supply So, I don't know if you can see Do you see the green wires? So, these are directly linked To the ethics port supply Nothing to do with the board directly Only with the ethics port supply That's how we pour it I think it's okay, yeah So, how does it look like? That's big, right? So, it's two metres high We have eight drawers So, up to 50 boards, I would say So, it's still, as you can see, a mess It's still undergoing work So, yeah, that's it So, I will let Antoine Do a small feedback on the board And then I will continue Yep, so some feedbacks on what we did Well, what failed, what worked Yeah, we launched it At the end of April this year And we have currently 35 boards in it With, as I said, contained an estimated capacity Of 50 boards As of now, I think we had a look Last week at the numbers We had more than 160 K tests On more than 30 unique boards in Kernel CI So, that means we added 35 boards In Kernel CI, but 30 of them are unique To Kernel CI This is good Actually, and this is why everybody Add a farm of boards into Kernel CI Because a lot of companies have access to unique boards That are not available While by the whole community So, some challenges Because you may assume It will just work But actually, when you're doing something like this Well, the actual test of the boards Will be pretty much straightforward But then you will need to debug Or test automation Software and hardware And this is maybe one tricky part Because you will encounter some failures And some new or unexpected uses Of Linux server For example, we have, as Quentin said Many devices connected to the Lava dispatcher So this means you will have lots of connection To a Sunnet or USB To a single machine For example, we had issues With using USB With a lot of devices connected to the same machine And we had to recompile our kernel To be able, well, just to have the machine work Working So this was one tricky part Also, if you have a look at the board Every board will be different So you will have to deal with Specific keyboard configuration For example, you can have many boards With a modified version of your boot Which is not mainline And you will have to deal with it Maybe it will be heavily modified And so you won't be able to use Common commands To boot a kernel Or maybe you will need to use Specific format for your image To be able to boot on this board So you will have to deal with this You may have to deal with hardware modifications Because some board will need to We need you to press a button To be able to boot it So if you want to automate the boot Then you will have to remove this button So it can be, well, one hardware modification And also you can deal with all boot loaders Because, well, a board is maybe Not supported into mainline You boot again And for example, in our lab We have one really old version Of your boot from 2004 So it was your boot 1.1.1 Which is quite old So you have to deal with this And the third point is really important Just expect everything to fail You will have failure in every part Of your lab When testing it Sometimes kernel CI guys Will tell you that a board is not working It may be not related to the board Actually But it may be related to your firm So you again will have to deal with this So for example You can have buggy serial connections Software services Or machines that are not working Across reboots So we had everything I told you we had it So we had to fix everything on this slide Well, last but not least Lava is one implementation Of software testing So it assumes that the board Are working in a certain way And sometimes it's just not true So you may have to patch lava For a given set of board Just to have them working In your lab Ok So it can be quite scary But well it's really useful To do it and it's not that difficult To fix this You just need time Some more documentation Well maybe the most Well not most important point But what we say today We have a lot of articles Or not blog Not every one of them Was published yet But we will have detailed On the order part Software part Can LCI part I guess Maybe Nope Well Also about the last part We will present you just after the slide Well On top of this link You have everything that is related To can LCI or lava So this is the actual documentation As said Quentin There are two versions of lava So the documentation may not be Fully updated Or may not Specify if it's for Version 1 Or 2 of lava So it can be also quite tricky To understand it But well again It's not that complicated So you need time And you need to have Quentin In your office Last part Remote control So we presented you How to build a border farm How to integrate it into Can LCI But you can also use it For other purposes We will just show One of them to you We are a bit short On time But well It's the break after So it should be okay So one of the uses We wanted to have With our farm Was to use it remotely Because we have some engineers Which are working at home Remotely So they do not have access Towards the board We can have in our office In Toulouse for example We also have some boards Only ones So if you want to Use them to develop And to use them Into Can LCI At the same time Then Well it's quite complicated To remove them From the board farm Every time You want to test something new And to put it again Every day For Can LCI To be able to run tests And well One important point Well nice one Is that You have a border farm So it's fully automated You just need a tool To be able to use it manually And so this is what we did Well we did Quentin did And it's called Well Lavabo Yeah So just A small follow up On the farm You can have Help from the community At the mailing list So I've not Noted it But it's easy to find On the internet And it's really useful So they are quick to answer And yeah That was a great help for me So Quickly Because we have no time Lavabo So For Lavabo Lavabo board oversuit Yeah Well we find the job before So it reuses The same tools Lavabo uses So we want it to be kissed So keep it simple Stupid So it will just Literally reuse Any tool Lavabo uses And we'll take full control As Lavabo is doing And it will authenticate users So it's really important Within a team of engineers So two people cannot Access the same board at the same time And it has to be To be fully compatible with Lavabo So for example If we work on a board We don't want it to run Can I see our jobs for example So for that Remember the small scheme I'll show you at the beginning Now Lavabo is on Green So basically It will just read You will install Lavabo server On your server machine So on the master Of Lavabo It will read configuration file To know how to connect to a serial How to put on or off the board Where to find it Then you will install Lavabo clients So called Lavabo On your computers On your engineer computer Via SSH And you will get Serial connection via SSH Parts or direction And files will be Uploadable To the TFTP directory Accessible to devices Via SFTP So that's a quick Introduction to Lavabo But there is more On the documentation But I will let Just one thing Lavabo server is not a demon So it's not something that is running Well, every time Ok So yeah It will just run once The Lavabo client is calling it So it's not re-eating your resources Lavabo is Based on the client server models So as I said The server must be on this So yeah Some requirements The server must be on the same machine As well Lavabo is hosted So multiple dispatchers Are not yet Handled, supported So no support for multi-node Lavabo You have to have one dedicated SSH Unix users on your Lavabo master So you can connect via SSH You have one SSH key Par Lavabo real users So one SSH key per engineer So you can authenticate them And Lavabo's connection commands So the way you get Cereconnection on Lavabo Should be tennet yet Maybe we'll Yeah, I mean you can Help us to get contact support And there is no support for Routefs On NFS Because that's quite hard We'll have to deal with Portal direction Things like that It's not really easy And we don't have a lot of Boards that are booting on NFS yet So we'll maybe work on that later So typical workflow Lavabo Allo you to List all the devices Available on Lavabo server It gives you the hostnames From when it is offline Since when And then you have the status Of each board And who put it offline So for example we have Omar Who reserved the Armada 3720 On September 21 So it was two weeks ago So you have to reserve it So for example for the chip You reserve the board So now it is attached Linked to your SSH key So you are the only one Allowed to access it Then you can upload Your camera, your DTB Your Routefs, whatever To your TFTP directory On the server And then reset Will reset your board So basically You will just Connect to the serial So that's done on the Engineer laptop You will get the serial And then you can reset the board If it fails to boot So it cannot crash or whatever And you pour it off And then you release Omar, release it please So that's it for the Small presentation of Lavabo I hope we have We have time to Well do a little demo But we'll see Some limitations So as I said No NFS for Routefs A single node So no multiple dispatchers yet So yeah We can work on that You can help us too Because yeah Well it's On our Github For that We have also the Lava configuration file On a different repository But you can steal them So yeah I think that's it for the For me I will let Antoine finish the talk No Thanks So we maybe have time for one or two questions If you want to stay just after Maybe we have five minutes To show you how Lavabo is working But first questions If you have maybe one or two questions So do you want to build A firm of board on your own? No Ok, well Yes, there is a microphone here Yeah If you want Yeah, a microphone Yeah Is the relay board Is it free To get the layout And software Firmware Is it open hardware? The relay board Is it open hardware? Open hardware No It's Mostly because We don't really document How to build it So we don't have the steps how to build it But if you ask us No problem we can help you But no it's not really open hardware Because for us it was really a specific location So yeah After all it's all It's just a shelf with drawers So yeah On the hardware part I think it's ok We didn't build it Actually the relay board So we just have to buy it It's not open hardware But if you want to build one Yeah, second question We have a microphone Does LavaBow connect with a real Lava database And takes the boards from the Lava database So ConLCI does not connect With a board No it's not related to ConLCI It's related to the configuration files Of Lava So Quentin showed you These configuration files with Well how to power board And it will read this configuration file Yeah but You have to Connect the board from the Lava database So nobody can On the Lava status can connect to it And you are the only permitted person Yeah, yeah Well you need access to SSH to your machine And so you need a key To be able to do this So it's secured by the SSH protocol So it's not Well our implementation But it's already working Yeah I think the question was How do we How do we say To Lava Now it's off Lava So we added Endpoints in the API to say that So now we just have to Call the API And just say Reserve the board Or put it outside Inside the Lava Yeah This could be a good part of Lava itself I think it would be nice To have a job like I added my own job For this Lava device now And I can communicate with it So it could be an own implementation Plug in for Lava Yeah okay The problem is Lava is done to automate tests Not to take control of the board So I don't know maybe Lava to do that But yet it's I think it's not really the purpose of Lava Thanks Thank you