lava-devel

lava-devel@lists.lavasoftware.org

68 discussions

Design meeting minutes from 2019-01-16

by Steve McIntyre

Hi folks, We held our regular weekly design meeting today via Hangout. Brief summary of discussion: * LAVA 2019.01 release + Tentatively planned for 24th January + Neil normally does the functional release tests, may need to take those over if he's still ill. + What should be included? Quick discussion of open Merge Requests: - !336 Milosz still testing - !333 - merge, looks good - !331 - merge, definitely needed - !328 - looks good - !324 - needs review - !323, !321 will wait - !309 - check and review - !302 - review - !295 will wait for discussion - !294 needs more work * BKK19 presentations? + lavafed/meta-lava "LAVA community enabled testing" + LAVA user forum Already requested + Bootloader testing (with Loïc Poulain) Would be great * Inviting community to the design meeting? + We've been talking about doing this for a while, but never actually got round to it. It's time we did! See below for details. + Agreed to send mail to lava-devel each week with summary of the minutes, with a link to the HO for the meeting itself [Steve] + Mail to -announce describing this [Steve] + If we ever overflow what hangouts will deal with, worry about it then + If we ever need private meetings, we can have those as needed * Access rights improvement Stevan is looking into revamping how access controls are implemented, to make things simpler/cleaner/faster. He'll add a ticket at git.lavasoftware.org and mail the -devel list with more details. * Decoupling scheduler from the frontend We were planning on discussing this at the sprint this week before it was postponed. Hoping to re-organise it soon... The LAVA design meeting is held weekly, every Wednesday at 13:00 to 14:00 UTC using Google Hangouts Meet: https://meet.google.com/qre-rgen-zwc Feel free to comment here or join us directly in the meeting. Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

7 years, 2 months

Linaro & LAVA at FOSDEM 2019

by Neil Williams

https://fosdem.org/2019/ (No registration is necessary for FOSDEM - if you can get to Brussels, you are welcome to just turn up on site. Avoid trying to park near the site unless you get there very early, use public transport.) https://fosdem.org/2019/practical/ https://fosdem.org/2019/stands/ If you haven't been to FOSDEM before, note that there will be a huge number of people attending FOSDEM (well over 8,000 are expected), so the only real chance of meeting up is to have a known meeting point. Hopefully, you'll have a chance to get to some of the 700 sessions which have been arranged over the 2 days. Linaro will have a stand at FOSDEM 2019 in the AW building. The stand will be on the ground floor, along the corridor from AW120 near MicroPython and PINE64. Various Linaro and LAVA people will be around the stand during the event, so this can act as a focal point for anyone wanting to talk about Linaro and or LAVA during FOSDEM. https://fosdem.org/2019/schedule/room/aw1120/ The AW building is near the car park, across from Janson and the H building. Various Linaro and LAVA people have been routinely attending FOSDEM for a number of years. If you are able to get there, we will be happy to see you. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 2 months

Require build procedure for lavacli

by Dasar, Yashwanth

Dear Lava Dev team, I cloned the LAVA source from git@github.com:Linaro/lava.git and able to build. From the said repo, I dont get "lavacli", "lava-coordinator" and "lavapdu-daemon". Please provide more information on source repos and build procedure. Thank you, -Yash

7 years, 2 months

Default patterns and fixup dicts in Lava-Test Test Definition 1.0

by Neil Williams

https://git.lavasoftware.org/lava/lava/issues/179 If your Lava-Test Test Definition 1.0 YAML files explicitly use a parse: block (like: https://git.linaro.org/qa/test-definitions.git/tree/automated/linux/ltp/ltp…) then this will remain supported in Definition 1.0. If you use the monitors or interactive test actions, this does not affect you at all. If you rely on LAVA to create a TestCase based on a command in the Lava-Test Test Definition just echoing "pass" or "fail", then this is the Default Pattern and this change will directly affect those test jobs. The current Default Pattern and Fixup are lifted directly from V1 (https://git.lavasoftware.org/lava/lava/blob/master/lava_common/constants.py…): # V1 compatibility DEFAULT_V1_PATTERN = "(?P<test_case_id>.*-*)\\s+:\\s+(?P<result>(PASS|pass|FAIL|fail|SKIP|skip|UNKNOWN|unknown))" DEFAULT_V1_FIXUP = { "PASS": "pass", "FAIL": "fail", "SKIP": "skip", "UNKNOWN": "unknown", } We've recently updated the documentation to drop mention of the default pattern support for the following reasons: * It has always been problematic to encode a Python regular expression in YAML. Failures are difficult to debug and patterns are global for the entire test operation. * The move towards more portable test definitions puts the emphasis on parsing the test output locally on the DUT using a customised parser. This has further advantages: * The pattern does not have to be mangled into YAML * The pattern can be implemented by a language other than Python * The pattern can change during the operation of the test shell, e.g. a different pattern may be required for setup than for the test itself. We are now starting to plan for Lava-Test Test Definition 2.0 with an emphasis on requiring portable test scripts and removing more of the lava_test_shell Test Helper scripts. Full information on 2.0 will be available early in 2019. As a first step, the generally unhelpful Default Pattern and Default Fixup dict are likely to be removed. If you need this support, the pattern can be added to your Lava-Test Test Definition 1.0 YAML files. In the next release, it is proposed that unless an explicit pattern is specified in the Lava-Test Test Definition 1.0 YAML file, then no pattern will be implemented. Processes which echo "pass" or "fail" would be ignored and no TestCase would be created. Let us know if there are any thoughts or problems on this proposal. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 3 months

Migrations and releases

by Neil Williams

When a new release is being planned, it is useful to give admins some notice if the release includes a database migration. Releases without migrations can be applied with minimal downtime (just the time needed to unpack the files and restart the daemons). LAVA is also planning changes to support scaling and high availability, these changes may involve creating multiple dockers accessing the same external database. This provides for no downtime when upgrading to a new LAVA release, each docker could be restarted independently, jobs can continue to be submitted etc.. However, as soon as the release includes even one database migration, scheduled downtime becomes unavoidable and services trying to submit jobs would get a HTTP502 error. All docker containers would have to be stopped before the database is migrated and then updated containers started which use the new code to match the effect of the migrations. To help admins with future releases, the plan is to "batch up" migrations into a single release and then give warning on lava-announce when work starts on that release (not at the point of announcing the release itself). Merge requests which include database changes will have the database changes label applied: https://git.lavasoftware.org/lava/lava/merge_requests?label_name%5B%5D=Data… Issues which are expected to require database changes will have the same label: https://git.lavasoftware.org/lava/lava/issues?label_name%5B%5D=Database+cha… Issues and merge requests with the label will be put into the same milestone and the milestone will mention that database changes are expected: https://git.lavasoftware.org/groups/lava/-/milestones/2?milestone%5Btitle%5… When developers are planning changes which include database migrations, please make sure that this is declared (on this list and in all issues or merge requests), the relevant label is attached and a suitable milestone is set. Avoid merging any MR which has a milestone ahead of the next release. Milestones are tracked here: https://git.lavasoftware.org/groups/lava/-/milestones One suggestion for developers would be to host the change which includes one or more migrations in a dedicated docker container and keep your localhost on the master branch. Comments? Problems? -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 3 months

Testing...

by Steve McIntyre

Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

7 years, 5 months

Design notes from 17th October 2018

by Neil Williams

https://git.lavasoftware.org/lava/ci-images/merge_requests/4 I've had problems getting Docker in Docker working on arm64. As the second main architecture for LAVA, I was looking at how to build arm64 docker images inside GitLab CI - using the same methods as the amd64 builds. A number of issues resulted: The DinD base images are complex and it's not obvious how to build an arm64 docker image which can run in privileged mode and build other docker images inside it - certainly not within our existing GitLab CI. The available arm64 hardware has lots of cores but is slow at single threaded operations. I manually built the arm64 docker images to run the unit tests outside of the GitLab CI, even with -n 18 support to use 18 of the 24 cores, it is still too slow to use on every change to every merge request. That then means that automatically building the arm64 docker images is less of an issue - we can simply run some arm64 tests when a git tag is pushed. The overall issue will be kept under review but for now, we'll be fine with manually rebuilding arm64 dockers from time to time and running arm64 tests only on tags. So the WIP for ci-images has been abandoned and the WIP on lava will be lower priority. Other merge requests were discussed too: https://git.lavasoftware.org/lava/lava/merge_requests/103 The XML_RPC support will gain documentation on how to use the allow_none setting in XMLRPC clients to help keep the newer XML_RPC function output consistent. https://git.lavasoftware.org/lava/lava/merge_requests/14 The skip_timeout support will be tweaked to use a boolean flag in the timeout block of the test action and the contribution guide updated to show a distinction that tags should relate to user/device data and elements relating directly to the code should use the structures instead. https://git.lavasoftware.org/lava/lava/merge_requests/12 Excessive messages will be changed to handle the trim inside the exception handler. These merge requests will get updates in the next few days. https://git.lavasoftware.org/lava/lava/merge_requests?scope=all&utf8=%E2%9C… There are a number of merge requests tagged with the 2018.10 milestone - these are the ones we are trying to get merged before making a new upstream release of LAVA. Finally, a reminder, this list is intended for developers of LAVA to support discussion of changes before or after a merge request is opened. Please abide by the Code of Conduct and Contribution Guide. https://www.lavasoftware.org/code-of-conduct.html https://master.lavasoftware.org/static/docs/v2/contribution-intro.html -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 5 months

Testy test 2

by Steve McIntyre

Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

7 years, 6 months

2026

2025

2024

2023

2022

2021

2020

2019

2018

lava-devel