LAVA requires a range of singleton daemon processes to schedule, organise,
publish and log the test job operations. 2017.12 will be retiring the
lava-server daemon and the /var/log/lava-server/lava-scheduler.log, moving
those operations into the lava-master daemon and the
/var/log/lava-server/lava-master.log. This is one of the steps in the
removal of V1.
This leads a substantial change to how admins approach an instance running
2017.12 or later.
When jobs don't appear to be running for some reason, the default action is
to check /var/log/lava-server/lava-scheduler.log - once the instance is
running 2017.12 or later, admins need to remember that it is correct for:
* /var/log/lava-server/lava-scheduler.log to be empty
* the status of the lava-server daemon to be active (exited)
* the lava-server service to not restart
At some point after 2017.12 has been running, admins can choose to archive
or purge /var/log/lava-server/lava-scheduler.log* and / or disable the
lava-server service using systemctl.
The scheduler from 2017.12 onwards will consist of:
* /var/log/lava-server/lava-master.log
* /var/log/lava-server/lava-logs.log
* the status of the lava-master daemon will be active (running)
* the lava-master service will restart when admins request it.
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
[ Related-ish to the discussion in the "Fastboot - Android boot image
apply-overlay" thread, but also slightly different so I'm starting a
new discussion here... ]
Hi folks,
We were just discussing in IRC about potential problems with Android
images in LAVA, in terms of fitting the overlay.
Ideally, the Android builds would have a rootfs configured to be as
small as possible - it's automatically resized to fit the available
space at first boot, and leaving space otherwise is
inefficient. However, if we're going to add the LAVA test overlay into
the rootfs, space needs to be left for it to fit. That's not
*necessarily* a problem, except that at build time the Android builds
don't know how much space we're going to need! This leads to a bit of
a chicken-and-eff problem.
Anibal has already hacked around this a little bit as a workaround in
a job definition - see
https://validation.linaro.org/scheduler/job/1652299/definition#defline92
In the lxc, he's converting and expanding the rootfs image to make
more space, then converting back ready for flashing. This is still
quite hacky - there's still no information available there about the
size of the LAVA overlay. It might fit now, but what happens if
there's a new LAVA version next month with (hypothetically) a much
bigger overlay?
So, I'm thinking about a better way to do things here, in 2 parts:
1 .At the point when we apply the overlay, we know roughly how big it
is and we could do the resizing of the image to fit directly
without needing this guesswork. It's a relatively easy thing to
do.
2. [Optionally] If we end up growing the rootfs image ourselves, it
*might* end up overflowing the size available when we come to
flash things, but "fastboot flash" will check this and abort. I
even suggested that (to fail more quickly) we could parse the GPT
partition table for size ourselves, but Nicolas pointed out that
not all jobs will necessarily have such a partition table.
Instead, *maybe* we could include a "maximum rootfs size"
parameter somewhere if we care. Otherwise, just rely on fastboot
doing the right thing.
Does this sound sensible?
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
Hello Lava team,
We have implemented new scripts to support flashing in our "power on" script.
This script manage the PDU, boot pins configuration of the board and an external ST flasher.
At the beginning of the job, the "power on" script is launched.
Then I got the following error message <line way too long ...> .
This cause the execution script to be interrupted, but the job is not interrupted and can continue without flashing the board.
I do not have any additional logs regarding this error on the LAVA web interface.
Our power on script is composed of several scripts that are "chained", script power on call another script,
that call another one.
Do you have an idea about this error ?
Details concerning our configuration :
* we use LAVA V2 ( version 06/2017 ).
* our jobs are pipelined jobs ( LAVA V2)
* Lava server // dispatcher are installed through dockers.
BR
Philippe
LAVA, until now, has packaged SysVinit files to manage the various daemons
but there have been longstanding problems with log rotation and the need to
carry redundant code to manage the daemonize process for python scripts.
This has allowed instances to support both SysVinit and systemd because
systemd automatically converts the SysVinit files to systemd service files.
Now that V1 has been removed, it has become possible and advantageous to
drop SysVinit support and move to only systemd support. This is expected to
mean that lava-dispatcher (and therefore lava-server) will depend on
systemd-sysv, i.e. systemd needs to be the init system to be able to start
the daemons upon which LAVA relies.
A default install of Debian Jessie and Stretch already defaults to using
systemd as the init system, so this does not necessarily involve any
changes.
If there are questions or issues with this, please reply to the lava-users
mailing list.
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
Hi all,
We are planning implementing a test that uses QDL (https://git.linaro.org/landing-teams/working/qualcomm/qdl.git/) for DragonBoard flashing.
Scenario:
after we flashed the binaries with QDL we want to check in the serial log if the boot sequence is correct.
Can we develop this test in LAVA?
If not, please recommend a test framework that can.
Thank you,
Alfred
See
https://lists.linaro.org/pipermail/lava-announce/2017-September/000037.html
2017.11 is the second release on the roadmap to the removal of V1. This is
the single largest change ever made to the LAVA packages.
* All dashboard URLs are permanently disabled in lava-server.
* All devices which were not enabled for V2 are now hidden and unusable.
* All V1 code has been removed from lava-dispatcher.
* All V1 documentation has been removed from lava-server-doc.
2017.11 disables all access to any V1 test data - including V1 only
devices. The data itself remains in the database but is not accessible via
any API.
If you have chosen to keep an archive of V1 test data and have not yet done
so, you should do this before installing this upgrade. At the very least,
you **must** have a backup of your postgresql database **before** you
upgraded to 2017.11 in order to make a V1 test data archive later.
2017.11 requires that **all** workers and each associated master are
upgraded to 2017.11 for test jobs to continue running. This is because
there have been very large changes to the directories and file layout
within both lava-server and lava-dispatcher associated with the removal of
the V1 components.
The LAVA software team have been checking ahead for the final stage of the
roadmap and plans are on track, as described.
http:// and https:// changes in django
======================================
A reminder, if you are accessing an instance using http:// (whether
localhost or not), then the changes described in the documentation **must**
be applied for the instance to operate correctly. This is a security change
in Django, not a change in LAVA.
https://staging.validation.linaro.org/static/docs/v2/pipeline-debug.html#us…
Symptoms include HTTP500 errors but can also include the inability to login
to an instance using LDAP or local django accounts, depending on your local
apache configuration.
Changes in 2017.11
==================
Changes in the 2017.11 release are described below, including the short git
commit hash. Use the git commit hash to go directly to that commit using a
URL like https://git.linaro.org/lava/lava-server.git/commit/?id=b19b9648a
for lava-server or
https://git.linaro.org/lava/lava-dispatcher.git/commit/?id=1451e3a4 for
lava-dispatcher.
Where the changelog message includes a story id like LAVA-552, that id can
be added to the base URL: https://projects.linaro.org/browse/ to find out
more about the change itself. e.g.
https://projects.linaro.org/browse/LAVA-552
All LAVA stories are publicly available without requiring a login.
2017.11 also includes large changes to the packaging of both lava-server
and lava-dispatcher. The prompts formerly used to configure a V1 remote
worker have been removed. Packaging is maintained at
https://github.com/Linaro/pkg-lava-server and
https://github.com/Linaro/pkg-lava-dispatcher
Packages for 2017.11 have been uploaded to Debian unstable and also the
LAVA repositories (for jessie-backports and stretch-backports).
lava-server
===========
a799fc6c Fix links back to the main instance
5b9656b6 Fix broken plural in header
b21f8c8f Fix crash in job_section_log
c9526f01 Document the LOG_SIZE_LIMIT setting in settings.conf
63b57c94 Remove lava-mount-masterfs
75b403f4 Remove add_device script
8ddea823 Add description about the disc space requirement
for pg_upgradecluster.
5c9dceb2 Remove TemporaryDevice imports
9b21ea48 Removed unused Worker functions
2accb4c3 Matching change to templates for directory change
1d384c4a Update docs regarding device-dictionary lava-server manage
command.
32472fac Port 77fd10e2 to scheduler.devices.get_dictionary
114bbfa5 LAVA-1093 - Add a management command to drop all materialized
views
8bc9d83a Update dashboard XML-RPC API help for api_version
bb090e96 LAVA-552 - add system.api_version support
77fd10e2 LAVA-1092 support passing a context to device_config
de7ad3aa Remove dashboard_app views and static files.
4bc68531 Remove templates from dashboard_app.
1a618c27 Remove unused functions
d50deca7 api: limit the number of jobs returned
59880e14 Fix HTTP 500 on devicetype health history
a39fecf5 Remove unused resources (css, js and images)
a32ac3b6 Rename base-bootstrap and content-bootstrap
7c108de1 job: print lava.job result in case of failure
b51c419f Remove old templates
a9139c1f Use bootstrap template
7915f18f Remove unused resources
7331901a scheduler.api.jobs.show: add failure_comment
71233bff Fix print syntax for python3 compatibility
936d5eca Remove unused tags
4ebb2a39 Remove unused sources
21a7eb18 Save more sql queries by caching values
4d0d867e Remove non pipeline jobs support
a6648dbd Retain docs on disabling V1 workers
8eac0d74 Revert "LAVA-950 set the master identity"
68573b1a Remove V1 dependencies
a8151559 timing: handle new start/end line format
26cc3ad0 Remove unnecessary js lib beautify.
c44009fa Simplify job view
e1da85d4 Fix loading of description.yaml
7b41f7ef Add documentation for secondary media writer parameters
1b4d3dd5 LAVA-1081 migrate instance name to settings
f3dc1987 Fix up typos from earlier changes
faa24f59 LAVA-1079 - remove HIDE_V1 and HIDE_V2 doc options
942b84c3 Remove unused functions and imports
e61a4831 LAVA-1056 Drop V1 documentation
126dce0c Fix crash introduced by 42451c9cc
f0b28214 Remove v1 codebase
31bb1bf0 Fix notification exception when query is used for data
comparison.
a6cff700 Remove last references to lava_dispatcher v1
043690d9 Remove references to lava_dispatcher v1
4c9e493c Remove dashboard_app traces from rest of the codebase.
c371b8ca drop link to removed page
1b1b638e LAVA-876 - Return empty data stubs for dashboard API calls.
919c10c2 Remove links to dashboard_app in the scheduler_app
1483e9fb Remove leftover from job wizard
f7a1c976 docker: allow passing extra options
42451c9c Use all_jobs_with_custom_sort when applicable
cc4ffd64 Fix broken links in example test job
0ca5d75c Drop the migration status page.
b37fe944 Add a device-type config for the rpi-3b in armv7 32bit mode
9e904a18 Revert "LAVA-876 - Remove access to Dashboard"
f07e0950 Fix warning regarding naive datetime
e8348425 Remove more references to dashboard_app
103a44be LAVA-876 - Remove access to Dashboard
d33c9c98 LAVA-876 - Remove access to Dashboard
b6fc46aa Revert "LAVA-1038 add a settings to archive the instance"
f75a333d Do not run dashboard test anymore
d9163445 Remove references to v1 jobs
addb61d9 bug 3268: fix lava-master crash with invalid logs
febf91b1 Improve advice on api/help
ac8b7df3 fix pep8 error
64025cf3 LAVA-1072 test all template connection syntax
10d5fbe1 Adjust U-Boot load addresses for tegra124 devices
to allow bigger kernels
f30ef936 LAVA-1065 - Remove dashboard_app urls server wide.
096a2f1c LAVA-1049 - Allow for .yml as well as .yaml for healthchecks
918f0bc7 Fix logic so addldapuser and mergeldapuser work for
all LDAP configs
36fcb3c2 Documentation changes for multiple uarts
b1de8acf Update instructions for migrating postgres
0ff08373 LAVA-1053 Results limit does not work for queries
f9e64aa1 Fix SQL request storm when listing jobs
2d9c4757 No need to save after get_or_create or Create()
8988cb36 LAVA-896 fix level in result export
219fa3dd LAVA-1073 - support for a second UART on a device
c934bbbe master: fix database reconnection
4f0e0e62 LAVA-950 set the master identity
316d77fb Expand the device integration guidance.
lava-dispatcher
===============
d91a5b99 Revert "Stop parsing kernel messages when the end of a
panic has been found"
1451e3a4 LAVA-1098 unassigned variable in read_feedback
437d57ba Rationalise the devices directory structure
bdffb3bf Add power control to pyocd
d9553680 Add feedback check to test shell
06588ddf Receive the udev device directly from the udev rule
d811b2a8 Fix license
65d6c6a6 Move arduino101 dfu example urls to images.v.l.o
61cff41c Only log when feedback content was found
0ba35392 Move juno removable URLs to images.validation.linaro.org
cb983d97 Cleanup after pytest runs
997265c2 LAVA-1086 add handler to listen to feedback
29a60e38 Add ConfigObj dependency for TFTP check
70bd3fab Fix prospector warnings
6edb8ef9 Fix missing import and other pylint issues
6f7f5f05 Remove lava-lxc-device-* scripts which are unused.
578b054b Use py.test
65c03eca docker: allow passing extra options
7b7d920a device-info should be yaml
ef8f7d4c Remove deprecated function
165e14f8 Fix linger period: set it to 10s instead of 5ms
49c500ac Fix double crash when the process crash early
7dbdc2b6 Add test case for secondary deployment writer tool parameters
969459c6 LAVA-1069 - migrate dispatcher device configs
9e8e5258 Use optargs to extend ci-run for python3
e1c1561b Fix python3 breakage in unit test
69277753 Read feedback when finalising connections
0fb44088 LAVA-1067 Refactor fastboot flash operations
9ac71872 Add missing import
94430958 Ensure finalize always finalises protocols
9d712364 Add option to not uniquify secondary image download paths
cdfd5909 Fix master cert handling for lava-run and lxc helper
73548f7a Rename dd params to tool for removable media
1802c3e8 Handle master and slave certs as filenames only
ed306477 Do not rely on SysV runlevel to ensure container is ready.
75b47c6a Remove loop mounts via guestfs, while applying
overlay to sparse image.
cd1152e3 Support archlinux and slackware rootfs
6fc024a5 Remove deprecated modules
ddf5d2fc Remove v1 code
5561be23 LAVA-1074 - second UART support
758a41a6 Allow configurable writes for secondary storage deployment
fb75db4a Add flag to disable uniquifying the download paths
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
Hi everyone!
I have recently upgraded our production server to 2017.10-1. Whenever anyone tries to login in the WEB UI, either the “403: Forbidden – CSRF verification failed” error is returned, or no error at all (for the latter, the default LAVA page is shown again, but with no login info).
I also tried creating a new superuser from the CLI. That worked, but I can’t use it to logon via the WEB UI, so I guess this has nothing to do with the user accounts stored in LAVA.
Is this triggered by a change in Django/LAVA?
Kind regards,
Dragoș
Hello everybody,
I am working with both Jenkins and lava and I thought it was possible to
change X attributes in charts to use Jenkins build number instead of a date.
In my job, I defined a metadata like this :
job_name: quad-ssh-host
device_type: ssh
*metadata: {jenkins-build: 725, job-context: nightly}*
timeouts:
job:
minutes: 10
action:
minutes: 3
connection:
seconds: 20
visibility: public
[…]
and I made a query that can select these jobs using job-context as a filter.
Then, in the chart, I wanted to use the jenkins-build value to group job
instead of a simple date, but the chart does not seem to be able to do that.
I made many tries on the lava 2017.2 version. I wonder whether I am
misusing lava charts or if it is an issue that need a fix.
Thanks in advance for any reply.
Jonathan
