From patchwork Tue Feb 7 18:54:11 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zygmunt Krynicki X-Patchwork-Id: 6679 Return-Path: X-Original-To: patchwork@peony.canonical.com Delivered-To: patchwork@peony.canonical.com Received: from fiordland.canonical.com (fiordland.canonical.com [91.189.94.145]) by peony.canonical.com (Postfix) with ESMTP id 6A12923E16 for ; Tue, 7 Feb 2012 18:54:15 +0000 (UTC) Received: from mail-iy0-f180.google.com (mail-iy0-f180.google.com [209.85.210.180]) by fiordland.canonical.com (Postfix) with ESMTP id E96B0A1805F for ; Tue, 7 Feb 2012 18:54:14 +0000 (UTC) Received: by iabz7 with SMTP id z7so14135118iab.11 for ; Tue, 07 Feb 2012 10:54:14 -0800 (PST) Received: by 10.50.15.231 with SMTP id a7mr28239622igd.8.1328640854187; Tue, 07 Feb 2012 10:54:14 -0800 (PST) X-Forwarded-To: linaro-patchwork@canonical.com X-Forwarded-For: patch@linaro.org linaro-patchwork@canonical.com Delivered-To: patches@linaro.org Received: by 10.231.169.210 with SMTP id a18cs133420ibz; Tue, 7 Feb 2012 10:54:12 -0800 (PST) Received: by 10.180.83.97 with SMTP id p1mr25178052wiy.19.1328640852089; Tue, 07 Feb 2012 10:54:12 -0800 (PST) Received: from indium.canonical.com (indium.canonical.com. [91.189.90.7]) by mx.google.com with ESMTPS id du1si14780419wib.3.2012.02.07.10.54.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Feb 2012 10:54:12 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of bounces@canonical.com designates 91.189.90.7 as permitted sender) client-ip=91.189.90.7; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of bounces@canonical.com designates 91.189.90.7 as permitted sender) smtp.mail=bounces@canonical.com Received: from ackee.canonical.com ([91.189.89.26]) by indium.canonical.com with esmtp (Exim 4.71 #1 (Debian)) id 1RuqB9-0006O9-Hv for ; Tue, 07 Feb 2012 18:54:11 +0000 Received: from ackee.canonical.com (localhost [127.0.0.1]) by ackee.canonical.com (Postfix) with ESMTP id 7F6DCE0785 for ; Tue, 7 Feb 2012 18:54:11 +0000 (UTC) MIME-Version: 1.0 X-Launchpad-Project: lava-dispatcher X-Launchpad-Branch: ~linaro-validation/lava-dispatcher/trunk X-Launchpad-Message-Rationale: Subscriber X-Launchpad-Branch-Revision-Number: 218 X-Launchpad-Notification-Type: branch-revision To: Linaro Patch Tracker From: noreply@launchpad.net Subject: [Branch ~linaro-validation/lava-dispatcher/trunk] Rev 218: Merge the 0.5.2 release Message-Id: <20120207185411.27145.76810.launchpad@ackee.canonical.com> Date: Tue, 07 Feb 2012 18:54:11 -0000 Reply-To: noreply@launchpad.net Sender: bounces@canonical.com Errors-To: bounces@canonical.com Precedence: bulk X-Generated-By: Launchpad (canonical.com); Revision="14747"; Instance="launchpad-lazr.conf" X-Launchpad-Hash: e075fc1cccb040db8193c3588059517c5edb0536 Merge authors: Zygmunt Krynicki (zkrynicki) ------------------------------------------------------------ revno: 218 [merge] committer: Zygmunt Krynicki branch nick: lava-dispatcher timestamp: Tue 2012-02-07 19:52:06 +0100 message: Merge the 0.5.2 release modified: doc/changes.rst doc/index.rst doc/installation.rst lava_dispatcher/__init__.py lava_dispatcher/client/base.py --- lp:lava-dispatcher https://code.launchpad.net/~linaro-validation/lava-dispatcher/trunk You are subscribed to branch lp:lava-dispatcher. To unsubscribe from this branch go to https://code.launchpad.net/~linaro-validation/lava-dispatcher/trunk/+edit-subscription === modified file 'doc/changes.rst' --- doc/changes.rst 2012-01-30 17:55:51 +0000 +++ doc/changes.rst 2012-02-07 18:50:34 +0000 @@ -1,10 +1,29 @@ Version History *************** +.. _version_0_5_2: + +Version 0.5.2 +============= + +* Fix https://launchpad.net/bugs/921632 - still submit some results even if + retrieve_results blows up +* Fix https://launchpad.net/bugs/925396 - lava-dispatcher exits when test + failed +* Minor documentation updates + +.. _version_0_5_1: + +Version 0.5.1 +============= + +* Fix broken rc check (Paul Larson) + .. _version_0_5_0: Version 0.5.0 -================================ +============= + * Add new android_install_binaries action * Fix problem when reporting failure messages that contain unicode * Refactor click-through workaround, and add support for new omap3 @@ -14,7 +33,7 @@ .. _version_0_4_5: Version 0.4.5 -================================ +============= * extend lmc timeout to 24 hours * retry until timeout for getting results * pass on timeout in PrefixCommandRunner.run @@ -22,21 +41,21 @@ .. _version_0_4_4: Version 0.4.4 -================================ +============= * Fix an issue with linaro-media-create timing out prematurely .. _version_0_4_3: Version 0.4.3 -================================ +============= * Workaround for license acceptance in lmc on snowball * Fix userdata deployment for origen and mx53 * Fix missing piece for errno 17 on deployment (bug #897918) .. _version_0_4_2: -Version 0.4.2(Milestone 2012.01) -================================ +Version 0.4.2 (Milestone 2012.01) +================================= * Job files can now specify the filesystem to use for the rootfs. * It is now possible to include an auth token in the job file so that results can be submitted to a private bundle stream. @@ -47,8 +66,8 @@ .. _version_0_4_1: -Version 0.4.1(Milestone 11.12) -============================== +Version 0.4.1 (Milestone 11.12) +=============================== * Add support for Origen * Snowball default config fixes * Add support for new snowball hwpacks @@ -68,8 +87,8 @@ .. _version_0_3_5: -Version 0.3.5(Milestone 11.11) -============================== +Version 0.3.5 (Milestone 11.11) +=============================== * Have soft_reboot look for a message that both android and regular images print * Update android demo job to download urls that will hopefully exist for a while * First pass at adding plugin support for lava actions @@ -87,8 +106,8 @@ .. _version_0_3_4: -Version 0.3.4(Milestone 11.10) -============================== +Version 0.3.4 (Milestone 11.10) +=============================== * Documentation for lava-dispatcher is now available from lava-dispatcher.readthedocs.org * Added support for snowball boards * Move bootloader prompt string to device_type configuration file @@ -96,8 +115,8 @@ .. _version_0_3: -Version 0.3(Milestone 11.09) -============================ +Version 0.3 (Milestone 11.09) +============================= * Local configuration data for lava-dispatcher is now stored in config files. (Please look at the README and examples of configuration) * A new kernel package can be specified for testing directly in the lava-dispatcher * The lava-dispatcher is now available as a package. @@ -105,15 +124,15 @@ .. _version_0_2: -Version 0.2(Milestone 11.08) -============================ +Version 0.2 (Milestone 11.08) +============================= * Transferring results from the test system to the dispatcher is now more reliable * i.MX53 support added * Support added for installing out-of-tree tests * Bug fixes: #815986, #824622, #786005, #821385 -Version 0.1(Milestone 11.07) -============================ +Version 0.1 (Milestone 11.07) +============================= * LAVA dispatcher now tries to make as much progress in the test run as possible despite failures of previous actions, and keeps track of which actions passed or failed rather than just whether the whole test run completed or not. * Trial support for snowball board * Bug fixes: #791725, #806571, #768453 === modified file 'doc/index.rst' --- doc/index.rst 2011-10-25 02:01:41 +0000 +++ doc/index.rst 2012-02-07 18:46:16 +0000 @@ -1,26 +1,15 @@ -.. LAVA Dispatcher documentation master file, created by - sphinx-quickstart on Fri Sep 23 10:15:12 2011. - You can adapt this file completely to your liking, but it should at least - contain the root `toctree` directive. +.. LAVA Dispatcher documentation master file, created by sphinx-quickstart on + Fri Sep 23 10:15:12 2011. You can adapt this file completely to your + liking, but it should at least contain the root `toctree` directive. LAVA Dispatcher Documentation ============================= -LAVA Dispatcher is to dispatch test jobs from server(master node) to the target boards in validation farm, and publish the test result back to dashboard. It is scheduled by validation scheduler, and it could also run as standalone. +LAVA Dispatcher is to dispatch test jobs from server(master node) to the target +boards in validation farm, and publish the test result back to dashboard. It is +scheduled by validation scheduler, and it could also run as standalone. .. seealso:: To learn more about LAVA see https://launchpad.net/lava -Contents: - -.. toctree:: - :maxdepth: 1 - - installation.rst - jobfile.rst - usage.rst - changes.rst - todo.rst - - 60 second example ================= @@ -38,14 +27,20 @@ Features ======== -* Ability to accept, parse and run a job which consists of different actions and test cases, then upload test result to LAVA Dashboard on an ARM target system. -* Support ARM target boards including Beagle, Panda, i.MX51 EVK, i.MX53 QuickStart and Snowball, more boards support is coming. -* Support Android system on Beagle, Panda and i.MX53 QuickStart board, more boards support is coming. +* Ability to accept, parse and run a job which consists of different actions + and test cases, then upload test result to LAVA Dashboard on an ARM target + system. +* Support ARM target boards including Beagle, Panda, i.MX51 EVK, i.MX53 + QuickStart and Snowball, more boards support is coming. +* Support Android system on Beagle, Panda and i.MX53 QuickStart board, more + boards support is coming. * Support for local user-defined configuration data for boards, device types. -* Extensible device types and boards configuration editing, can add new device and new board. -* Make use of the output of LAVA test, which is Linaro Dashboard Bundle format, upload test results to the LAVA Dashboard for result archiving and analysis. +* Extensible device types and boards configuration editing, can add new device + and new board. +* Make use of the output of LAVA test, which is Linaro Dashboard Bundle format, + upload test results to the LAVA Dashboard for result archiving and analysis. -.. seealso:: See what's new in :ref:`version_0_3_4` +.. seealso:: See what's new in :ref:`version_0_5_2` .. todo:: @@ -55,17 +50,19 @@ ==================== This documentation may be out of date, we try to make sure that all the latest -and greatest releases are always documented on http://lava-dispatcher.readthedocs.org/ - +and greatest releases are always documented on +http://lava-dispatcher.readthedocs.org/ Source code, bugs and patches ============================= -The project is maintained on Launchpad at http://launchpad.net/lava-dispatcher/. +The project is maintained on Launchpad at +http://launchpad.net/lava-dispatcher/. -You can get the source code with bazaar using ``bzr branch lp:lava-dispatcher``. -Patches can be submitted using Launchpad merge proposals (for introduction to -this and topic see https://help.launchpad.net/Code/Review). +You can get the source code with bazaar using ``bzr branch +lp:lava-dispatcher``. Patches can be submitted using Launchpad merge proposals +(for introduction to this and topic see +https://help.launchpad.net/Code/Review). Please report all bugs at https://bugs.launchpad.net/lava-dispatcher/+filebug. @@ -82,6 +79,7 @@ jobfile.rst usage.rst changes.rst + code.rst todo.rst * :ref:`genindex` === modified file 'doc/installation.rst' --- doc/installation.rst 2011-10-09 07:17:05 +0000 +++ doc/installation.rst 2012-02-07 18:48:04 +0000 @@ -1,4 +1,3 @@ - .. _installation: Installation @@ -24,36 +23,59 @@ Creating a SD/MMC card with master image ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -You will need to have a card containing a 'master image' for your -board. The process of creating a master image is outlined on +You will need to have a card containing a 'master image' for your board. The +process of creating a master image is outlined on https://wiki.linaro.org/Platform/Validation/Specs/MasterBootImage. -The master image is a stable, default image the system can boot into for deployment and recovery. It's a simple modification of an existing stable image, and does not take long to create. Once you've created one for your board, you may want to consider making a dd image of it for future use. We do not provide dd images for this already. Due to differences in size of SD cards, it's likely that doing so would either waste a lot of space if you have a larger card, or be competely useless if you have a smaller sd card. +The master image is a stable, default image the system can boot into for +deployment and recovery. It's a simple modification of an existing stable +image, and does not take long to create. Once you've created one for your +board, you may want to consider making a dd image of it for future use. We do +not provide dd images for this already. Due to differences in size of SD cards, +it's likely that doing so would either waste a lot of space if you have a +larger card, or be competely useless if you have a smaller sd card. Setup the image and test partitions ----------------------------------- -* Start with a stable Linaro image from the current, or previous cycle. For instance, the nano, or headless images make a good starting place. Using linaro-media-create, create an sdcard with this image, and the hardware pack for your board. (minimum 8GB sd card is recommended, but 4GB can work also). -* Using parted (or gparted, etc), shrink the root partition so that only 1-1.5GB or so is used (Make sure to leave at least 2G free on the card). -* Create an additional primary partition (should normally be partition 3), of about 70MB. Format it as vfat and give it the label testboot. -* Create partition 4 as an Extended partition, using the remainder of the space on the card. -* Create partition 5 (logical partition) using 2GB. Format it as ext3, and give it the label testrootfs -* Finally, create one more logical partition using the remainder of the space. It should be vfat formatted, and have the label sdcard (NB: This is only needed if you want to test android images. If you don't wish to test android, this can be skipped) +* Start with a stable Linaro image from the current, or previous cycle. For + instance, the nano, or headless images make a good starting place. Using + linaro-media-create, create an sdcard with this image, and the hardware pack + for your board. (minimum 8GB sd card is recommended, but 4GB can work also). +* Using parted (or gparted, etc), shrink the root partition so that only + 1-1.5GB or so is used (Make sure to leave at least 2G free on the card). +* Create an additional primary partition (should normally be partition 3), of + about 70MB. Format it as vfat and give it the label testboot. +* Create partition 4 as an Extended partition, using the remainder of the space + on the card. +* Create partition 5 (logical partition) using 2GB. Format it as ext3, and give + it the label testrootfs +* Finally, create one more logical partition using the remainder of the space. + It should be vfat formatted, and have the label sdcard (NB: This is only + needed if you want to test android images. If you don't wish to test android, + this can be skipped) Prepare the master image ------------------------ -* Boot the image created above on your test board, and attach to the serial console -* Ensure that networking is set up so that the default network interface is automatically started. Generally you will want to use dhcp for this. For example, if your network interface is eth0, make sure that /etc/network/interfaces contains something like this:: +* Boot the image created above on your test board, and attach to the serial + console +* Ensure that networking is set up so that the default network interface is + automatically started. Generally you will want to use dhcp for this. For + example, if your network interface is eth0, make sure that + /etc/network/interfaces contains something like this:: auto usb0 iface usb0 inet dhcp -* Edit /etc/hostname and /etc/hosts to change the hostname to "master". This will allow easy detection of which image we are booted into. +* Edit /etc/hostname and /etc/hosts to change the hostname to "master". This + will allow easy detection of which image we are booted into. * Install the following packages: * wget * dosfstools -* If you want to test your own build kernel by a deb package(see following example job file for detail), you need to add linaro-media-tools support in master image:: +* If you want to test your own build kernel by a deb package(see following + example job file for detail), you need to add linaro-media-tools support in + master image:: # apt-get install bzr python-distutils-extra python-testtools python-parted command-not-found python-yaml python-beautifulsoup python-wxgtk2.6 # bzr branch lp:linaro-media-tools @@ -63,14 +85,16 @@ Setting up serial access ^^^^^^^^^^^^^^^^^^^^^^^^ -To talk to the target test systems, the dispatcher uses a tool called conmux. If you are running Ubuntu 11.04 or later, conmux is in the archives and can be easily installed [TODO: point to ppa for conmux installation -lt 11.04]. +To talk to the target test systems, the dispatcher uses a tool called conmux. +If you are running Ubuntu 11.04 or later, conmux is in the archives and can be +easily installed [TODO: point to ppa for conmux installation -lt 11.04]. Configuring cu and conmux ------------------------- -For LAVA development and testing using only locally attached resources, -you should be able to make use of most features, even without the use of -special equipment such as a console server. +For LAVA development and testing using only locally attached resources, you +should be able to make use of most features, even without the use of special +equipment such as a console server. First install conmux and cu:: @@ -103,12 +127,16 @@ Configuring conmux ------------------ -Connect a development board to a local serial device (e.g. ttyUSB0). You may have permission problem with cu running as root under conmux. - -Configuration files for conmux are stored under /etc/conmux. It can be configured for either local connections (via serial or usb), or remote configurations such as console servers. Configurations for each board you wish to connect to should be stored in it's own .cf file under /etc/conmux. - -Create a configuration file for your board under /etc/conmux which -should look something like this:: +Connect a development board to a local serial device (e.g. ttyUSB0). You may +have permission problem with cu running as root under conmux. + +Configuration files for conmux are stored under /etc/conmux. It can be +configured for either local connections (via serial or usb), or remote +configurations such as console servers. Configurations for each board you wish +to connect to should be stored in it's own .cf file under /etc/conmux. + +Create a configuration file for your board under /etc/conmux which should look +something like this:: listener panda01 application console 'panda01 console' 'cu -l /dev/ttyUSB0 -s 115200' @@ -131,12 +159,16 @@ conmux-console panda01 (use ~$quit to exit) -Another example config, a remote console server on 10.1.1.1 port 7777 attached to a board we will call beagle01:: +Another example config, a remote console server on 10.1.1.1 port 7777 attached +to a board we will call beagle01:: listener beagle01 socket console 'beagle01 console' '10.1.1.1:7777' -.. seealso:: If you are using a snowball with serial USB, then you'll need to follow `this guide `_ +.. seealso:: + + If you are using a snowball with serial USB, then you'll need to follow + `this guide `_ Installation Options ^^^^^^^^^^^^^^^^^^^^ @@ -166,11 +198,11 @@ Using source tarball -------------------- -To install from source you must first obtain a source tarball from bazzar branch or from `Launchpad `_:: +To install from source you must first obtain a source tarball from bazzar +branch or from `Launchpad `_:: bzr branch lp:lava-dispatcher To install the package unpack the tarball and run:: sudo python setup.py install - === modified file 'lava_dispatcher/__init__.py' --- lava_dispatcher/__init__.py 2012-01-30 18:43:45 +0000 +++ lava_dispatcher/__init__.py 2012-02-07 18:51:38 +0000 @@ -18,4 +18,4 @@ # along # with this program; if not, see . -__version__ = (0, 5, 1, "final", 0) +__version__ = (0, 5, 2, "final", 0) === modified file 'lava_dispatcher/client/base.py' --- lava_dispatcher/client/base.py 2012-01-19 11:16:49 +0000 +++ lava_dispatcher/client/base.py 2012-02-07 18:42:14 +0000 @@ -255,7 +255,7 @@ LavaClient manipulates the target board, bootup, reset, power off the board, sends commands to board to execute. - The main interfaces to execute commands on the board are the *_session() + The main interfaces to execute commands on the board are the \*_session() methods. These should be used as context managers, for example:: with client.tester_session() as session: