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.