As the first job, this is a simple emulated test which does not need any extra hardware, it does not use protocols and runs as a single job.
Note
This kind of test is generally termed singlenode.
comments - V2 uses YAML for job submission precisely because YAML supports comments. Please use comments liberally. Comments are preserved in the job definition which can be viewed and downloaded from the instance. Comments are not passed to the dispatcher.
device_type - a label which must match the type of device declared on the instance to which you want to submit this job. Each device type can have one or more devices available. In this case, qemu.
job_name - your own free text name for this job. This name is used in the server side tables but has no further relevance for the dispatcher. There is no need to make this into a single long word with V2 - any valid YAML string is allowed, so commas, capitalisation and whitespace are fine.
timeouts - a range of things can go wrong inside a LAVA test job, so the test writer needs to indicate how long parts of the job should take. This allows LAVA to fail jobs which have hung and return the device to scheduling for the next test job. Timeouts at the top level include the job, the default timeout per action and can include the default timeout for the device to respond using a connection.
See also
priority - supports values if high, medium or low. The scheduler considers the job priority when ordering the queue to consider which job should run next. Do not abuse priority.
visibility - supports values of public, personal and group and controls who is allowed to view the job and the results generated by the job. This includes whether the results are available to queries and to charts.
context - Not all testjobs will use a context, it is available to override some of the server-side device configuration templates. In this case, arch: amd64 sets the template to use the qemu-system-x86_64 executable when starting the emulation.
# Sample JOB definition for an x86_64 QEMU
device_type: qemu
job_name: QEMU pipeline, first job
timeouts:
job:
minutes: 15
action:
minutes: 5
priority: medium
visibility: public
context:
arch: amd64
Each test job needs a list of actions, comprising of deploy, boot and test.
Deployment methods are identified by the to parameter, for QEMU the supported deployment method is to tmpfs. The image to deploy is specified as an image dictionary which supports the formatting of the options to QEMU and the compression algorithm to use to decompress the download prior to passing to QEMU.
Arguments to QEMU need to include the filename, often embedded within a specific option string. To achieve this, LAVA supports a label for the image which will be substituted into the option.
actions:
- deploy:
timeout:
minutes: 5
to: tmpfs
images:
rootfs:
image_arg: -drive format=raw,file={rootfs}
url: https://images.validation.linaro.org/kvm-debian-wheezy.img.gz
compression: gz
os: debian
The other role of a deploy action is to prepare the overlay which will contain the test shell scripts and repositories. These will be added to the booted image and then executed automatically, generating the results for the test job.
Certain aspects of executing tests on a booted device require knowledge about which OS will be running after the device has booted. This is particularly relevant when the test scripts may require additional dependencies to be installed in the running system. The test scripts need to know whether to use apt or yum or something else to do the installation work. Some other OS deployments may change other elements within the test, so the test job submission will fail if the os parameter is not set or is set to an unrecognised string.
Supported operating systems include debian, ubuntu, oe (for OpenEmbedded) and fedora.
https://images.validation.linaro.org/kvm-debian-wheezy.img.gz is downloaded and then decompressed using the gz algorithm to create a file called kvm-debian-wheezy.img in a tmpfs location. This location is then substituted into the image_arg:
-drive format=raw,file=/tmp/tmp.23FDsf/kvm-debian-wheezy.img
One of the primary roles of the boot action parameters is to ensure that the correct pipeline is constructed for this test job. The specified method is used to match against the available boot methods. In this case, the boot method is to call QEMU. The qemu boot method also needs the media parameter set to tmpfs to distinguish this from other boot methods.
- boot:
method: qemu
media: tmpfs
prompts: ["root@debian:"]
Note
prompts - this is a list of prompt strings which the test writer MUST specify in advance and which LAVA will use to determine whether the boot was successful. One of the specified prompts must match before the test can be started. When building or downloading images prepared by others, it is essential that the test writer records the information on what prompt will be presented when the system boots into that image successfully. If this information is not available from the location from which you downloaded the image, you will need to ask for that information or boot the image yourself and identify the prompt.
The test action block in the first job contains two sets of definition parameters, each consisting of:
The test action block in the first job also includes a timeout as an example of how to specify a timeout for a particular section of the job.
- test:
timeout:
minutes: 5
definitions:
- repository: git://git.linaro.org/qa/test-definitions.git
from: git
path: ubuntu/smoke-tests-basic.yaml
name: smoke-tests
- repository: https://git.linaro.org/lava-team/lava-functional-tests.git
from: git
path: lava-test-shell/single-node/singlenode03.yaml
name: singlenode-advanced
See also
Back to your first job Job Submission.