03:14 <jramsay> Hi! I'm trying to set up an account on gitlab.freedesktop.org but not getting the verification email. Tried twice so far. The first time it came in too late and my request timed out. Second time I didn't get the verification email at all, just the rejection one.

03:20 <jramsay> Just tried to sign up again... Maybe this time it'll get here in time :)

08:42 <jramsay> Aha. This time it got here in time!

11:47 <eric_engestrom> could someone share the env vars they have set up on their runner (for mesa test jobs)? I'm struggling a bit (mostly about BM_BOOTFS, but I want to sanity-check the rest as well)

11:49 <mupuf> eric_engestrom: I don't have any set

11:57 <eric_engestrom> $ ./install/bare-metal/poe-powered.sh

11:57 <eric_engestrom> Must set /boot files for the TFTP boot in the job's variables

11:57 <eric_engestrom> if I don't set it

12:00 <mupuf> ah, you are using the bare metal infra. Sorry, I have no experience with it

12:09 <eric_engestrom> I don't know what we should be using honestly ^^

12:14 <mupuf> Well, for Mesa, there are 3 options, lava, baremetal, and the valve infra

12:15 <mupuf> the first 2 are the most mature, while valve infra is still under development

12:16 <mupuf> valve-infra is meant to be a bit more modern, easier to maintain, and self-configuring, but there are only 3 deployments of it, so the documentation is clearly lacking

12:29 <eric_engestrom> but /me is going to lunch now

12:33 <mupuf> well, baremetal is the simplest one: you need a gateway, install the gitlab runner, and expose as many runners as you have boards. All the configuration as to how to turn on the machine and interact with it is then in Mesa.

12:34 <mupuf> Lava is a CI system of its own, and gitlab runners may queue jobs there and get results. It handles the deployment and what needs to be executed, but needs to be told that via a yaml job description file

12:36 <mupuf> That means that all that Mesa has to do is to generate the rootfs and the job description, then queue a job and wait for it to be over.

12:36 <mupuf> This allows sharing machines between multiple gitlab instances, or other projects (like Kernel CI in the case of Lava and Collabora).

12:38 <daniels> eric_engestrom: if you look into poe-powered.sh, you’ll see what you need to set for the device - how to turn it on, where it can find an exported NFS mount, where its /boot should be, etc

12:39 <daniels> tanty or jasuarez can probably give you an example for how your internal ones are set up

12:39 <daniels> there are docs but I’m not sure how up to date they are

12:42 <mupuf> As for Valve Infra, it follows the same model as Lava, but it is more based on container (you don't have to... but it is the easiest), and most configuration is auto-generated (adding new machines to CI and GitLab is literally a single button press away). Also, the infra itself is netbooted over the internet, which makes updates and disaster recovery easier

12:47 <mupuf> eventually, it would be great to host the infra's netboot infrastructure on fd.o so that one admin could take care of all the farms remotely

13:58 <daniels> mupuf: yeeeesssss and no; some might be fine with that, but I know for Google in particular remote management is a no-go

13:58 <mupuf> daniels: What do you mean?

14:00 <daniels> mupuf: I believe for the Google device farm that those devices can't be subject to remote management, e.g. from the netboot being on fd.o, and that it needs to be more self-contained

14:00 <daniels> something I'm sure you're familiar with from Intel ;)

14:01 <mupuf> aaahhhh!

14:01 <mupuf> fair-enough :) I was more talking for the smaller farms. I thought you meant to say we could not use GCE to host the infra to netboot other machines from... which made little sense

14:05 <daniels> haha

14:11 <eric_engestrom> thx mupuf for the explanation of lava vs baremetal, that's the bit I was missing

14:11 <eric_engestrom> daniels: I'll talk to tanty, but jasuarez is off until the end of the year