On Mon, 28 Jan 2019 at 16:21, Dan Rue <dan.rue(a)linaro.org> wrote:
>
> On Mon, Jan 28, 2019 at 09:24:26AM +0000, Milosz Wasilewski wrote:
> > On Fri, 25 Jan 2019 at 23:00, Dan Rue <dan.rue(a)linaro.org> wrote:
> > >
> > > More updates! Described below, referenced links go to source:
> > > - beaglebone-black is now working for me [1]
> > > - ser2net containerized [2]
> > > - LAVA upgrade process is documented [3]
> > > - Squid container added; nginx images hack removed [4]
> > >
> > > The beaglebone-black branch represents what's now an actual working
> > > docker-compose environment for my bbb, using a recent u-boot (this
> > > turned out to be the hardest part - totally unrelated to docker). I
> > > ended up running NFS and TFTP on the host and mounting the paths into
> > > the dispatcher. I'd like to containerize those still, but NFS is a bit
> > > difficult in particular and I just wanted to see things work.
> > >
> > > The beaglebone-black branch is back to using the dispatcher without
> > > rebuilding it. I did this by breaking ser2net into its own container
> > > that can be found at danrue/ser2net and used as follows:
> > >
> > > version: '3.4'
> > > services:
> > > ser2net:
> > > image: danrue/ser2net:3.5
> > > volumes:
> > > - ./ser2net/ser2net.conf:/etc/ser2net.conf
> > > devices:
> > > - /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
> > >
> > > The best part is running something like this to spy on the serial port during testing:
> > >
> > > docker-compose exec dispatcher telnet ser2net 5001
> > >
> > > The LAVA upgrade has been documented in the README, but it's simple
> > > enough I'll reproduce it here:
> > >
> > > 1. Stop containers.
> > > 2. Back up pgsql from its docker volume
> > >
> > > sudo tar cvzf lava-server-pgdata-$(date +%Y%m%d).tgz /var/lib/docker/volumes/lava-server-pgdata
> > >
> > > 3. Change e.g. `lavasoftware/amd64-lava-server:2018.11` to
> > > `lavasoftware/amd64-lava-server:2019.01` and
> >
> > Is the content of /var/lib/lava-server/default/media/job-output/ also
> > preserved in this scenario? If not, this dir should also probably be
> > mapped into a volume so it is moved between migrated versions.
>
> Oh, good catch. Fixed with a docker volume @
> https://github.com/danrue/lava-docker-compose/blob/master/docker-compose.ym…
>
Today I managed to get LAVA and SQUAD working together in
containerized setup. Here is the repository with docker-compose:
https://github.com/mwasilew/lava-docker-compose
I didn't update README yet. It's still not ideal as there might be
race conditions starting SQUAD (only first time when DB is not yet
populated). One big issue is lack of cmd line tools for user
management in SQUAD. This means that admin user can be added but
password can't be set. I'm planning to copy this code from LAVA to
provide the same options. So far I managed to submit 1 QEMU job to
LAVA via SQUAD proxy and retrieve the results once the job finished.
Comments are welcome :)
milosz
Hi all,
After looking to squad-worker's log, I can see it reports "WorkerLostError".
On the web ui, the last build on project summary page is not updated
with last test results, but these results are visible if we click on this
build.
Moreover, the build is still on "unfinished" state while there is no test
running,
and it gives no reason about why the build is considered unfinished.
Is it possible the build is not updated because of the worker facing errors
?
You can see the worker's log in attachment.
Best regards,
Axel
Hi,
Yesterday during SQUAD sync we discussed strategies for marking
baselines instead of having them marked automatically as a previous
builds. This has been suggested before here, and here.
By default, every finished build becomes the baseline of the next
finished build.
Two alternatives to tell SQUAD not to mark a finished build as
baseline are as follows (to be implemented):
a) go to build's page > build settings > check 'ignore as baseline'
option; anyone with write permissions to that build's project is
allowed to change its settings;
b) calling qa-reports.l.o/api/createbuild passing 'is_baseline=false'
as POST before calling qa-reports.l.o/api/submitjob
In absence of 'is_baseline', the build will be marked as baseline
by default, for backwards compatibility.
Before discussing edge cases, take example below (considering option b
above is being used to submit builds to Squad):
+------------+-----------------+-------------+
| build | is_baseline | baseline |
+------------+---------------- +-------------+
| build101 | false | build100 |
| build102 | false | build100 |
| build103 | ----- | build100 |
| build104 | ----- | build103 |
| build105 | false | build104 |
| build106 | false | build104 |
+------------+-----------------+-------------+
1. If build104 is later manually marked as not being a baseline,
through UI, then build103 automatically becomes the current baseline.
2. If in the event above, Squad will *NOT* re-run test comparisons for
build106 and build105 against build103.
I think we discussed other edge cases, but I can't remember them now.
Charles
Hi everyone,
Atm, I'm running 2 servers.
One is for staging and one for production.
On each server, I have one docker running LAVA and one docker running SQUAD.
>From SQUAD-PROD to LAVA-STAGING, I can submit job, fetch results etc,
everything is working fine.
Same from SQUAD-STAGING to LAVA-PROD.
But, from SQUAD-PROD to LAVA-PROD, or from SQUAD-STAGING to LAVA-STAGING,
the test submission fails.
Squad-worker returns and error saying connection timed out.
If I curl LAVA-PROD from SQUAD-PROD, it works. Same if I curl LAVA-STAGING
from SQUAD-STAGING. So it looks like they can communicate after all.
Any idea what could be the problem?
Best regards,
Axel
