lava-announce

lava-announce@lists.lavasoftware.org

1 participants
142 discussions

Upcoming changes in 2018.7

by Neil Williams

Advance notice of some changes coming in 2018.7 {% set device_type = 'foo' %} is going away =========================================== The purpose of any item in the device dictionary or device-type template is to provide information to lava-run to operate the test job. As far as lava-run is concerned, the device_type is completely meaningless. Device type is a database object, a component of scheduling and administration. So in 2018.7, all device-type Jinja2 templates have been updated to move this to a comment and the schema has been updated to remove the device_type field. If you have local Jinja2 templates which use {% set device_type = 'foo' %}, this needs to be changed to: {# device_type = 'foo' #} or if your template uses: device_type: foo This needs to be removed or commented out: # device_type: foo Any mention of device-type in a device dictionary will be ignored. This also means that deploying 2018.7 will involve changes to most upstream device-type templates. If you use an admin tool like salt, ansible, puppet etc. then it is worth making this change ahead of time. In the Harston lab, we create a code review against the git repo containing the device-type templates. When the admin is ready to upgrade a particular instance, the changes from the review are applied before the package upgrade is started. This prevents dpkg interrrupting the upgrade with prompts about changed configuration files whilst keeping the device-type templates under version control. Database configuration is now upstream ====================================== Previous releases have relied on the Debian packaging to do the work of setting up the PostgresQL database and managing database migrations during installation when a database already exists. We took this upstream so that we could manage the process in Python instead of shell, partly because the psql commands require some complex quoting which is very difficult to read and understand in shell. The other advantage is to have more eyes on the database setup code and to have formal code review of changes. In due course, it may also be helpful with the use of LAVA with docker. Availability ============ 2018.7 is likely to be available on or after 24th July 2018. At that point, Debian will still be handling the migration to Python3.7 which has caused issues in a range of Python packages with new keywords. https://tracker.debian.org/pkg/lava On request, we will not be uploading 2018.7 directly to Debian unstable until this transition is complete. As far as we can tell at the moment, there are no changes required within the LAVA codebase but there are a lot of Python dependencies which are yet to be fixed. This will also delay the arrival of 2018.7 into buster and stretch-backports in Debian. 2018.7 will be available from the LAVA repositories on images.validation.linaro.org once the release is ready. I'll make a separate announcement with the full list of changes at that time. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 6 months

Re: [Lava-announce] [Lava-users] How to add pub key to download source code after LAVA create the container

by Neil Williams

On Fri, 6 Jul 2018 at 09:41, Yuan, ZhanghuiX <zhanghuix.yuan(a)intel.com> wrote: > Hi LAVA mainters, > > > > Nice to meet you. > > I want to add my pub key after LAVA installed container. > Unless you configure LXC to allow this (and that is outside the scope of this list), there is no remote access to the container. Adding the public key will not make it possible to SSH into the container. Hacking sessions are not supported in the LXC. Think of the LXC as a transparent layer on the worker. It is not a separate virtual machine. What are you trying to achieve? If you want to access the rootfs of an LXC, you can do so by logging in to the worker and using the standard LXC support. If you want to push files from the LXC to a remote location, you can use the publishing support: https://staging.validation.linaro.org/static/docs/v2/publishing-artifacts.h… This is not a LAVA constraint, this is a reality of using LXC. > But I don’t which parameters should I need add in my job xx.yaml file. > > Could you give me some help and advice. > > > > > > >>>>>>>>>>>>>>> Some part information of my xx.yaml file: > <<<<<<<<<<<<<<<<<<<<<<<<<< > > > > actions: > > - deploy: > > timeout: > > minutes: 300 > > to: lxc > > os: ubuntu > > packages: [python, wget, unzip, python-pexpect, python-serial, > openssh-server] > > > > - boot: > > prompts: > > - '[root(a)(.*) /]#' > > timeout: > > minutes: 300 > > method: lxc > > > > - test: > > timeout: > > minutes: 300 > > gefinitionsg > > - run: > > steps: > > lava-test-shell: echo "------------------------------------- > debug 1 -----------------------" > > lava-test-shell: wget --no-proxy -q > http://otcpkt.bj.intel.com/downloads/pubkey/sys_oak.zip > > lava-test-shell: mkdir -p ~/.ssh > > lava-test-shell: unzip sys_oak.zip -d ~/.ssh > > definitions: > > - repository: ssh:// > sys_oak@git-amr-4.devtools.intel.com:29418/pk_osi_test-source.git > > from: git > > path: <device>/<test_type>_lxc.yaml > > name: <test_type>-<device> > > params: > > BUILD_NUMBER: <build_number> > > IMAGE_URL: <image_url> > > PRODUCT: <build_name> > > IRC_USER: "sys_oak" > > PUB_KEY: "ssh-rsa > AAAAB3NzaC1yc2EAAAADAQABAAABAQDCDJvT5UPE*************************** > > > > >>>>>>>>>>>>>>> Some part information of my xx.yaml file: > <<<<<<<<<<<<<<<<<<<<<<<<<< > > > > > > > > > > > > Best Regards > > Zhanghui Yuan > > OTC Production Kernel Integration Test > _______________________________________________ > Lava-users mailing list > Lava-users(a)lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lava-users > -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 7 months

Changes to running unit tests

by Neil Williams

After the security hotfix, a number of other security changes are being made. One which will affect developers running unit tests involves the permissions of /etc/lava-server/instance.conf Each installation of lava-server will set the permissions of this file to 0o640 and the owner to the LAVA_DB_USER configuration value (by default, named lavaserver). This is to protect production instances as this file contains the database password. -rw-r----- 1 lavaserver lavaserver 181 Jun 25 08:59 /etc/lava-server/instance.conf Developers need to ensure that the user running the unit tests is now part of this group, e.g. $ sudo adduser <username> lavaserver Otherwise, a permission error will be raised when trying to create the devel database used by the lava-server unit tests: PermissionError: [Errno 13] Permission denied: '/etc/lava-server/instance.conf' See also https://review.linaro.org/#/c/26068/ -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 7 months

2018.5.post1 Security hot fix

by Neil Williams

2018.5.post1 ============ During routine development, a new security scanning tool (bandit) was used on the LAVA codebase. Three security problems were found relating to the Job Submit UI and the loading of YAML files through XMLRPC. The problems date back to 2013, possibly earlier, so all releases of LAVA are affected. Fixes were developed and have now been released. https://review.linaro.org/#/c/25917/ Remove the ability to paste URLs in the submit page https://review.linaro.org/25918 Use requests instead of urlopen https://review.linaro.org/25919 Use yaml.safe_load when parsing user data Thanks to Remi Duraffort for identifying and fixing the issues. Note: These changes are not trivial to backport to previous releases. It is possible but some familiarity with the codebase will be required. We have packed a lot of changes into the time since the end of the migration and we are hoping to have a more stable time ahead. The LAVA software team recommend that all instances look to upgrade to 2018.5.post1. Our apologies for these problems. We are NOT aware of any exploits using these issues but now that the problems are public, it is prudent to apply the available fixes before anything happens. We expect to make more use of bandit and similar tools in future. CVE's have been requested but we don't have the CVE numbers back at this time. The production repo now carries these changes as 2018.5.post1-1+stretch An upload to Debian unstable will follow in due course. (The Debian security team were notified once we had a fix.) An upload to Debian Stretch to update 2016.12-1 is being prepared. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 7 months

2018.5 Production release

by Neil Williams

This is the first full release from the combined source tree. The expected direction of the LAVA codebase is to add more devices and the work of device integration is and has always been difficult. Merging the codebase removes an unnecessary hurdle in integrating new devices and smoothes the process of ensuring that existing integrations are maintained by generating dispatcher test files directly from the server templates. (This has been a problem in previous releases - static device configuration files in lava_dispatcher unit tests hid problems arising from changes to the templates in lava_scheduler_app. The unit tests are now more representative of real test job processing.) As a validation framework, our own unit test and CI support is a key technical component. lava_scheduler_app and lava_dispatcher modules will remain tightly integrated, using ZMQ to allow for physical separation. Combining the tree also makes it easier to update the documentation each time a new device is integrated. The new lava-common binary package allows lava-server to be installed without needing lava-dispatcher - this will reduce the number of dependencies required on instances with multiple workers where there are no devices attached to the master. The default remains to install lava-dispatcher alongside lava-server - use the --no-install-recommends option, as per the updated documentation. There are changes required in Debian for this release and those will take some time. See https://ftp-master.debian.org/new.html and https://ftp-master.debian.org/new/lava_2018.5-1.html (It is not necessary for every package in that queue to be processed before the LAVA upload is processed, some packages are held back for specific reasons.) Once the LAVA upload clears NEW, the old lava-dispatcher and lava-server source packages will be removed from Debian. One key advantage of this change within Debian is that all lava packages will migrate together - this will prevent a recurrence of the recent problem when lava-dispatcher was delayed arriving in backports but lava-server was accepted, causing installation failures. Both lava-server and lava-dispatcher binary packages depend on the same version of lava-common. When upgrading, lava-common should be added automatically. If not, use dist-upgrade or list the packages explicitly to let apt add the new package. e.g. $ sudo apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following NEW packages will be installed: lava-common The following packages will be upgraded: lava-dev lava-dispatcher libprocps6 procps Once lava-common is installed, if a master has no devices attached, admins can choose to remove lava-dispatcher and the extra dependencies can also be removed. *Check the list of packages to be removed on each instance* for packages required by other tools on the master, e.g. local admin scripts and similar. $ sudo apt update $ sudo apt upgrade or to list packages explicitly: # master with devices (may also have workers): $ sudo apt update $ sudo apt install lava-server lava-dispatcher # or for workers: $ sudo apt install lava-dispatcher # or for master without devices: $ sudo apt install lava-server $ sudo apt remove lava-dispatcher $ sudo apt-get --purge autoremove lava changes ============ 4a4bde2a1 LAVA-999 Export master and logger config 6f50e1145 LAVA-1315 add option to update existing users ff8d9f882 Update device-types to match my lab config 809ae34ea Use InfrastructureError for uefi menu timeout e52d83dc6 Stop the Overlay tests duplicating the base class 099f19599 LAVA-1310 separate the template unit tests 198283abb Drop Python2 xmlrpc support 13fa6bdef Fix support for scheduler.jobs.definition a40fe8664 Fix query results export to CSV. b18e74ca9 Create lava_common for Timeout and Exceptions ece1a46d4 Generate device configuration from templates e2d0f4b36 LAVA-1324 QEMU usage of KVM accelerator 59e0ab091 Extend timeouts in example test jobs 4269cc55a Merge branch 'master' into coordinator 7f49853f0 Complete fastboot sequence cannot be governed in device dictionary. 50d69d971 Update instructions for merged codebase e2de099f4 LAVA-1316 Instant scheduling edd48e0b1 signals: always add health_check field 1bbaec1e2 Allow to create health-check directly e0cddeb5e Create admin log entries when looping 2489bcbc8 Add auto-login to fastboot sequence of hi6220 device types. 13a4b5923 Drop debug line to update pipeline_reference da933a151 Add support for optionally running using pytest-3 51c81f659 Test decompression during download streams 3d2541d00 docker: always run with --rm 1cdd275aa Fix ResetDevice comment to match what it actually does. db2775001 Allow to sleep after the usb serial appeared 391595bcc LAVA-1309 - pre-* commands should be called with minus-lxc d524354f7 Add an helper to list all keys of an action namespace 9bfe50d84 Expand command lists in device dictionaries 0ff09a569 LAVA-1173 - allow for matching parents of nodes 3b5f47bf7 Make device_info validate errors unique dad039adb Allow for multiple udev rules in a single file 80ca5346a LAVA-1203 - Allow multiple callback URLs in notify action 120181cb6 ci-run should stop on first error bed5fcb20 Allow dispatcher unit tests to generate device config a3cc054f3 Implementation of recovery mode deploy and boot 47b184796 Print the url when validating file:// download 8d1ffad00 dispatcher: raise a TestError for invalid regexp fb39a9da8 Factorize compatiblity code 4511d4de6 monitor: log the start message c18752652 Fix broken unit test 84769209a Exclude Retired devices from invalid_template check 534f1a9b8 LAVA-1300 - fail if static devices cannot be found 235f17d35 Add the end time to the Recent job errors table e18d27c5a Update templates for changes from Harston lab fa0d9125f Update second UART example jobs 600fc7b4e ci-run: Remove some of the unused args and clean it up for jenkins 36fee805b Revert "Remove unused and obsolete requirements.txt" 2e051cb6d Remove any generated top level init.py 2060d7851 LAVA-1298 fix references to old repositories 1978274d1 Treat kernel panics as a job failure d920b7825 Remove unused and obsolete requirements.txt ed9039e87 LAVA-1297 - Incorporate changes to run jobs without LXC fabd4a44f Port to python3 and fix prospector warning e98737c55 LAVA-1286 Raise JobError if 'params' is not a dict 5af7a7f74 compression: do not use shell=True a4e1ac09b device-types: add meson-gxbb-nanopi-k2 2e84699d8 Port classes to python3 only 6a02322a1 device-types: add meson-gxl-s905x-libretech-cc 968873081 publisher: do not duplicate logs 05d119426 Send the wait-all role reply 80a912d7e Add a ./ci-run script 02a83fed4 Fix waitall with a role support 33644d89e Port to new daemon support with systemd service a1d9f99e3 Explicitly allow wait-all to occur before send 8b2e3feb0 Add a status check script a4cfb1b90 LAVA-489 Python3 support 1c570a0f8 add the gitreview file for lava-coordinator 210e4b7cf bump version -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 8 months

Re: [Lava-announce] [Lava-users] Merging the LAVA code source

by Neil Williams

On 24 April 2018 at 14:09, Zoran S <zoran.stojsavljevic.de(a)gmail.com> wrote: > > Sorry, but this was only a notification of a decision already taken and > implemented by > > the development team. The change itself was not and is not up for > discussion on this list. > > Sorry to be (brutal) honest with you and Linaro. ;-) > > I (sincerely) expect in The Future you/Linaro will be MUCH (much) more > serious with some responsibilities to this list, and to your/Linaro > Lava architecture? > This is a user list. It is not a development list. I remain unconvinced that you, personally, understand the LAVA architecture and design let alone our aims and objectives. > > Or... I expect out there that will be some more serious > people/companies with some more serious testing environment. I hope > for this to happen (competition is All Good, don't you think)! ;-) > > Do we have agreement here (I truly hope so)?! :-) > Not really. LAVA is absolutely serious about automation validation. I disagree with all the rest of your assumptions. > > Zoran Stojsavljevic > > On Tue, Apr 24, 2018 at 10:02 AM, Neil Williams > <neil.williams(a)linaro.org> wrote: > > On 24 April 2018 at 08:21, Zoran S <zoran.stojsavljevic.de(a)gmail.com> > wrote: > >> > >> > Not true. The master produces the configuration which is fed to the > >> > dispatcher - the two are very directly tied > >> > at the level of what devices can support and how that support is used > by > >> > test jobs. Changes and fixes in the > >> > device-type templates will change how the dispatcher uses the code > >> > support to control the device. > >> > >> With all due respect, Sir, I would not agree/would disagree to by > >> your/Linaro's currently presented architecture. > > > > > > Sorry, but this was only a notification of a decision already taken and > > implemented by the development team. The change itself was not and is > not up > > for discussion on this list. > > > >> > >> On Mon, Apr 23, 2018 at 4:06 PM, Neil Williams < > neil.williams(a)linaro.org> > >> wrote: > >> > On 23 April 2018 at 14:54, Zoran S <zoran.stojsavljevic.de(a)gmail.com> > >> > wrote: > >> >> > >> >> > lava-server and lava-dispatcher have been merged into a single > source > >> >> > repository - lava > >> >> > >> >> If you ask me, this is the (very) questionable decision. Indeed!? > >> >> > >> >> lava-server is the front-end manager of the whole Lava test > >> >> environment, while lava-dispatcher is the back-end. > Connected/splitted > >> >> by ZMQ protocol. And... They should be separately maintained > >> > > >> > > >> > Not true. The master produces the configuration which is fed to the > >> > dispatcher - the two are very directly tied at the level of what > devices > >> > can > >> > support and how that support is used by test jobs. Changes and fixes > in > >> > the > >> > device-type templates will change how the dispatcher uses the code > >> > support > >> > to control the device. The two have always been maintained by the same > >> > team > >> > and in a tightly integrated manner. > >> > > >> >> > >> >> , since > >> >> they represent (very) different things. Essentially, they do (very) > >> >> different tasks. They are, after all, apples and oranges. > >> > > >> > > >> > The bulk of the expected work from here on is Device Integrations. > Each > >> > new > >> > device integration typically involves changes to the dispatcher to > >> > support > >> > new deployment / boot methods as well as new templates for the device > >> > configuration. Combining the codebase allows those changes to be more > >> > easily > >> > verified because the output of the device configuration templates can > be > >> > fed > >> > directly to the lava-dispatcher code changes in the dispatcher unit > >> > tests. > >> > > >> > Previously, this has resulted in static device configuration files in > >> > the > >> > dispatcher unit tests and that has caused problems. > >> > > >> >> > >> >> > >> >> In other words, if you update/buy advanced/more expensive apples, you > >> >> also force testers to update for nuthin'/buy for the loss the same > >> >> oranges, they had before?! > >> > > >> > > >> > Not true. the packages are built from a single source package. That > does > >> > not > >> > mean that the binary packages need to be updated on the actual > >> > instances. > >> > > >> > Up until now, lava-server has always depended on the latest version of > >> > lava-dispatcher. That specific dependency is being removed as part of > >> > this > >> > change. > >> > > >> > Nevertheless, the principle remains that the lava-master and > lava-slave > >> > should be updated together so that the device configuration is in line > >> > with > >> > the dispatcher support. See compatibility settings in the > documentation. > >> > > >> > https://lava.codehelp.co.uk/static/docs/v2/simple-admin.html#index-5 > >> > > >> > > >> > > >> >> > >> >> > >> >> Is it the wise decision??? > >> >> > >> >> Two cents worth lamenting/analysis, > >> >> Zoran > >> >> _______ > >> >> > >> >> On Thu, Apr 19, 2018 at 3:41 PM, Neil Williams > >> >> <neil.williams(a)linaro.org> > >> >> wrote: > >> >> > This is for particular note for developers as it changes the way > that > >> >> > reviews happen. > >> >> > > >> >> > If you've noticed a few reviews being abandoned, this is why. > >> >> > > >> >> > lava-server and lava-dispatcher have been merged into a single > source > >> >> > repository - lava > >> >> > > >> >> > lava-coordinator will follow in time, to ease the update of > >> >> > lava-coordinator > >> >> > to Python3. > >> >> > > >> >> > This will, in future, allow easier testing of device integrations > by > >> >> > allowing the lava_scheduler_app unit tests to be linked to the > >> >> > lava_dispatcher unit tests and have a single review which adds both > >> >> > sides of > >> >> > the device support. > >> >> > > >> >> > There will be a lot of testing, as normal, so staging will be > moving > >> >> > to > >> >> > packages built from the new source repository tree. > >> >> > > >> >> > The old lava-server.git and lava-dispatcher,git repositories will > >> >> > become > >> >> > read-only and will get no further code changes. All changes will be > >> >> > done > >> >> > in > >> >> > lava.git > >> >> > > >> >> > https://git.linaro.org/lava/lava.git/ > >> >> > > >> >> > The documentation will be updated over the next few days. > >> >> > > >> >> > -- > >> >> > > >> >> > Neil Williams > >> >> > ============= > >> >> > neil.williams(a)linaro.org > >> >> > http://www.linux.codehelp.co.uk/ > >> >> > > >> >> > _______________________________________________ > >> >> > Lava-announce mailing list > >> >> > Lava-announce(a)lists.linaro.org > >> >> > https://lists.linaro.org/mailman/listinfo/lava-announce > >> >> > > >> >> _______________________________________________ > >> >> Lava-users mailing list > >> >> Lava-users(a)lists.linaro.org > >> >> https://lists.linaro.org/mailman/listinfo/lava-users > >> > > >> > > >> > > >> > > >> > -- > >> > > >> > Neil Williams > >> > ============= > >> > neil.williams(a)linaro.org > >> > http://www.linux.codehelp.co.uk/ > > > > > > > > > > -- > > > > Neil Williams > > ============= > > neil.williams(a)linaro.org > > http://www.linux.codehelp.co.uk/ > -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 9 months

2018.4.post2 hotfix release

by Neil Williams

2018.4.post2 hot fix is now available. This is the first release built from the combined source tree but the actual code changes are restricted to fixes for decompression of downloaded files, specifically .zip and .xz handling. Python3 only and Stretch only. Now available from the LAVA repositories, production-repo. https://staging.validation.linaro.org/static/docs/v2/installing_on_debian.h… Changes ======= fe70ac6ca Update version.py for repos with no tags 1f7c5b5f1 Fix typo in 86362f and add debug 11c5ab57e Do not attempt to unzip on the fly -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 9 months

Re: [Lava-announce] [Lava-users] Merging the LAVA code source

by Neil Williams

On 24 April 2018 at 08:21, Zoran S <zoran.stojsavljevic.de(a)gmail.com> wrote: > > Not true. The master produces the configuration which is fed to the > dispatcher - the two are very directly tied > > at the level of what devices can support and how that support is used by > test jobs. Changes and fixes in the > > device-type templates will change how the dispatcher uses the code > support to control the device. > > With all due respect, Sir, I would not agree/would disagree to by > your/Linaro's currently presented architecture. Sorry, but this was only a notification of a decision already taken and implemented by the development team. The change itself was not and is not up for discussion on this list. > On Mon, Apr 23, 2018 at 4:06 PM, Neil Williams <neil.williams(a)linaro.org> > wrote: > > On 23 April 2018 at 14:54, Zoran S <zoran.stojsavljevic.de(a)gmail.com> > wrote: > >> > >> > lava-server and lava-dispatcher have been merged into a single source > >> > repository - lava > >> > >> If you ask me, this is the (very) questionable decision. Indeed!? > >> > >> lava-server is the front-end manager of the whole Lava test > >> environment, while lava-dispatcher is the back-end. Connected/splitted > >> by ZMQ protocol. And... They should be separately maintained > > > > > > Not true. The master produces the configuration which is fed to the > > dispatcher - the two are very directly tied at the level of what devices > can > > support and how that support is used by test jobs. Changes and fixes in > the > > device-type templates will change how the dispatcher uses the code > support > > to control the device. The two have always been maintained by the same > team > > and in a tightly integrated manner. > > > >> > >> , since > >> they represent (very) different things. Essentially, they do (very) > >> different tasks. They are, after all, apples and oranges. > > > > > > The bulk of the expected work from here on is Device Integrations. Each > new > > device integration typically involves changes to the dispatcher to > support > > new deployment / boot methods as well as new templates for the device > > configuration. Combining the codebase allows those changes to be more > easily > > verified because the output of the device configuration templates can be > fed > > directly to the lava-dispatcher code changes in the dispatcher unit > tests. > > > > Previously, this has resulted in static device configuration files in the > > dispatcher unit tests and that has caused problems. > > > >> > >> > >> In other words, if you update/buy advanced/more expensive apples, you > >> also force testers to update for nuthin'/buy for the loss the same > >> oranges, they had before?! > > > > > > Not true. the packages are built from a single source package. That does > not > > mean that the binary packages need to be updated on the actual instances. > > > > Up until now, lava-server has always depended on the latest version of > > lava-dispatcher. That specific dependency is being removed as part of > this > > change. > > > > Nevertheless, the principle remains that the lava-master and lava-slave > > should be updated together so that the device configuration is in line > with > > the dispatcher support. See compatibility settings in the documentation. > > > > https://lava.codehelp.co.uk/static/docs/v2/simple-admin.html#index-5 > > > > > > > >> > >> > >> Is it the wise decision??? > >> > >> Two cents worth lamenting/analysis, > >> Zoran > >> _______ > >> > >> On Thu, Apr 19, 2018 at 3:41 PM, Neil Williams < > neil.williams(a)linaro.org> > >> wrote: > >> > This is for particular note for developers as it changes the way that > >> > reviews happen. > >> > > >> > If you've noticed a few reviews being abandoned, this is why. > >> > > >> > lava-server and lava-dispatcher have been merged into a single source > >> > repository - lava > >> > > >> > lava-coordinator will follow in time, to ease the update of > >> > lava-coordinator > >> > to Python3. > >> > > >> > This will, in future, allow easier testing of device integrations by > >> > allowing the lava_scheduler_app unit tests to be linked to the > >> > lava_dispatcher unit tests and have a single review which adds both > >> > sides of > >> > the device support. > >> > > >> > There will be a lot of testing, as normal, so staging will be moving > to > >> > packages built from the new source repository tree. > >> > > >> > The old lava-server.git and lava-dispatcher,git repositories will > become > >> > read-only and will get no further code changes. All changes will be > done > >> > in > >> > lava.git > >> > > >> > https://git.linaro.org/lava/lava.git/ > >> > > >> > The documentation will be updated over the next few days. > >> > > >> > -- > >> > > >> > Neil Williams > >> > ============= > >> > neil.williams(a)linaro.org > >> > http://www.linux.codehelp.co.uk/ > >> > > >> > _______________________________________________ > >> > Lava-announce mailing list > >> > Lava-announce(a)lists.linaro.org > >> > https://lists.linaro.org/mailman/listinfo/lava-announce > >> > > >> _______________________________________________ > >> Lava-users mailing list > >> Lava-users(a)lists.linaro.org > >> https://lists.linaro.org/mailman/listinfo/lava-users > > > > > > > > > > -- > > > > Neil Williams > > ============= > > neil.williams(a)linaro.org > > http://www.linux.codehelp.co.uk/ > -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 9 months

Re: [Lava-announce] [Lava-users] Merging the LAVA code source

by Neil Williams

On 23 April 2018 at 14:54, Zoran S <zoran.stojsavljevic.de(a)gmail.com> wrote: > > lava-server and lava-dispatcher have been merged into a single source > repository - lava > > If you ask me, this is the (very) questionable decision. Indeed!? > > lava-server is the front-end manager of the whole Lava test > environment, while lava-dispatcher is the back-end. Connected/splitted > by ZMQ protocol. And... They should be separately maintained Not true. The master produces the configuration which is fed to the dispatcher - the two are very directly tied at the level of what devices can support and how that support is used by test jobs. Changes and fixes in the device-type templates will change how the dispatcher uses the code support to control the device. The two have always been maintained by the same team and in a tightly integrated manner. > , since > they represent (very) different things. Essentially, they do (very) > different tasks. They are, after all, apples and oranges. > The bulk of the expected work from here on is Device Integrations. Each new device integration typically involves changes to the dispatcher to support new deployment / boot methods as well as new templates for the device configuration. Combining the codebase allows those changes to be more easily verified because the output of the device configuration templates can be fed directly to the lava-dispatcher code changes in the dispatcher unit tests. Previously, this has resulted in static device configuration files in the dispatcher unit tests and that has caused problems. > > In other words, if you update/buy advanced/more expensive apples, you > also force testers to update for nuthin'/buy for the loss the same > oranges, they had before?! > Not true. the packages are built from a single source package. That does not mean that the binary packages need to be updated on the actual instances. Up until now, lava-server has always depended on the latest version of lava-dispatcher. That specific dependency is being removed as part of this change. Nevertheless, the principle remains that the lava-master and lava-slave should be updated together so that the device configuration is in line with the dispatcher support. See compatibility settings in the documentation. https://lava.codehelp.co.uk/static/docs/v2/simple-admin.html#index-5 > > Is it the wise decision??? > > Two cents worth lamenting/analysis, > Zoran > _______ > > On Thu, Apr 19, 2018 at 3:41 PM, Neil Williams <neil.williams(a)linaro.org> > wrote: > > This is for particular note for developers as it changes the way that > > reviews happen. > > > > If you've noticed a few reviews being abandoned, this is why. > > > > lava-server and lava-dispatcher have been merged into a single source > > repository - lava > > > > lava-coordinator will follow in time, to ease the update of > lava-coordinator > > to Python3. > > > > This will, in future, allow easier testing of device integrations by > > allowing the lava_scheduler_app unit tests to be linked to the > > lava_dispatcher unit tests and have a single review which adds both > sides of > > the device support. > > > > There will be a lot of testing, as normal, so staging will be moving to > > packages built from the new source repository tree. > > > > The old lava-server.git and lava-dispatcher,git repositories will become > > read-only and will get no further code changes. All changes will be done > in > > lava.git > > > > https://git.linaro.org/lava/lava.git/ > > > > The documentation will be updated over the next few days. > > > > -- > > > > Neil Williams > > ============= > > neil.williams(a)linaro.org > > http://www.linux.codehelp.co.uk/ > > > > _______________________________________________ > > Lava-announce mailing list > > Lava-announce(a)lists.linaro.org > > https://lists.linaro.org/mailman/listinfo/lava-announce > > > _______________________________________________ > Lava-users mailing list > Lava-users(a)lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lava-users > -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 9 months

Merging the LAVA code source

by Neil Williams

This is for particular note for developers as it changes the way that reviews happen. If you've noticed a few reviews being abandoned, this is why. lava-server and lava-dispatcher have been merged into a single source repository - lava lava-coordinator will follow in time, to ease the update of lava-coordinator to Python3. This will, in future, allow easier testing of device integrations by allowing the lava_scheduler_app unit tests to be linked to the lava_dispatcher unit tests and have a single review which adds both sides of the device support. There will be a lot of testing, as normal, so staging will be moving to packages built from the new source repository tree. The old lava-server.git and lava-dispatcher,git repositories will become read-only and will get no further code changes. All changes will be done in lava.git https://git.linaro.org/lava/lava.git/ The documentation will be updated over the next few days. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 9 months

← Newer
1
...
6
7
8
9
10
11
12
...
15
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-announce