Re: [Linaro-validation] Reproducing LAVA setup in Qualcomm lab - issues with Dragonboard410c device connection to LAVA
On 11 February 2016 at 18:20, Elster, Constantine celster@qti.qualcomm.com wrote:
Dear Neil / Linaro validation support team,
Please see below our previous correspondence on configuring Dragonboard 410c with LAVA instance.
Since then we migrated to the pipeline model and our goal at the moment is:
To have a well configured and responsive board with the LAVApipeline instance
To have a simple test job that runs on our board + LOGSWe see two options to achieve this:
By running:sudo lava-dispatch --target < device configuration YAML > < test-job YAML
--output-dir=/tmp/test/
Not recommended. You lose all the advantages of the scheduler, the results handling, queries and charts as well as online access to the logs, data export and history. However, this is part of the development and debugging of the device configuration YAML. Just don't stop at that point, it is a simple step to migrate that to a device type template.Templates only start to look hard when the template is optimised.
By defining the device dictionary
There is no template for this board either, at the moment, but that isn't a problem.
https://validation.linaro.org/static/docs/pipeline-admin-example.html
This example works from a device working in the deprecated dispatcher (which your board is, although the available config upstream is only for android/fastboot, you have local config for the jobs you want to run).
In order to have a device configuration YAML for #1, you are most of the way to having a device-type template. For the template to be used upstream, it would need to look more like the other templates to avoid code duplication but a local template can (as the example above mentions) be a simple YAML file without any templating support. Equally, if you only have one board, then the device dictionary can be minimal and the device type template will work fine as that bare YAML file. (Effectively, every device of that type on that instance gets exactly the same config.)
Don't let the jinja2 file extension put you off. It's just there for syntax highlighting support in editors - the output of rendering the template is YAML. It works in exactly the same way as django HTML templates in web apps. Anything which jinja doesn't recognise as a command, it outputs unchanged.
A device dictionary only needs to contain the 'extends', so if your YAML template is called sbc8016e.jinja2 then the minimal device dictionary would be: {% extends 'sbc8016e.jinja2' %}
You only need to put more commands into the device dictionary if there are more than one devices of this type on that one instance - then the template uses {{ variable }} and the device dictionary uses {% set variable = 'blah' %} where 'blah' differs from one device to the next.
Would appreciate your support on the item #1:
We already have a deployed image on our board, we want to connectvia SSH and run a simple (or sample) test job.
a. how our device configuration YAML should look like?
A cut down version of this: https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/p...
Cut down to something like this:
device_type: beaglebone-black
parameters: none:
commands: connect: telnet localhost 6000
actions: deploy: methods: ssh: options: - '-o' - 'Compression=yes' - '-o' - 'UserKnownHostsFile=/dev/null' - '-o' - 'PasswordAuthentication=no' - '-o' - 'StrictHostKeyChecking=no' - '-o' - 'LogLevel=FATAL' - '-l' - 'root ' - '-p' - '22' host: 172.16.200.165 identity_file: device/dynamic_vm_keys/lava boot: connections: ssh: methods: ssh:
Don't rely on GMail not mangling the above - use http://yaml-online-parser.appspot.com/?yaml=&type=json and make sure it parses as valid YAML.
b. how our test-job YAML (a simple pass/fail test, just to demonstrate it runs in the log files) should look like?
A working ssh-host job file for beaglebone-black is attached.
Thank you,
Alfred, Costi.
-----Original Message----- From: Fradkin, Alex Sent: Thursday, February 04, 2016 12:38 AM To: Neil Williams Cc: nicolas.dechesne@linaro.org; Elster, Constantine; Ziskind, Alfred; Sedlak Grinbaum, Anna Hanna Subject: Re: Reproducing LAVA setup in Qualcomm lab - issues with Dragonboard410c device connection to LAVA
Hi Neil,
Thanks for detailed answer.
We'll try to use new 2016.2 LAVA.
Thanks,
Alex
From: Neil Williams neil.williams@linaro.org
Sent: Tuesday, February 2, 2016 18:46
To: Fradkin, Alex
Cc: nicolas.dechesne@linaro.org; Elster, Constantine; Ziskind, Alfred; Sedlak Grinbaum, Anna Hanna
Subject: Re: Reproducing LAVA setup in Qualcomm lab - issues with Dragonboard410c device connection to LAVA
On 2 February 2016 at 13:20, Fradkin, Alex alexf@qti.qualcomm.com wrote:
Hi Neil/Niko,
Please always use the mailing list support as I'm not always the best person to respond to all queries.
https://validation.linaro.org/static/docs/support.html
For this query, the linaro-validation mailing list is the best selection.
https://lists.linaro.org/mailman/listinfo/linaro-validation
linaro-validation@lists.linaro.org
We are trying to reproduce LAVA installation in our lab, but we have some trouble with device connection to LAVA server.
Our device currently have preinstalled Debian or OpenEmbedded images and we just want to execute tests on it (no need to create images at moment).
Bear in mind that the new 2016.2 release moves the new pipeline dispatcher out of "developer mode" where it has been for over a year and into production. For devices like this, it is worth looking at that support too. This deprecates the old dispatcher (using JSON submissions and .conf files) but there is plenty of time - the old support will stay around for the majority of 2016.
In general, it is much better to work with a device which is already working in another LAVA instance. The device configuration for devices hosted at the Cambridge LAVA lab is in https://git.linaro.org/lava/lava-lab.git.
Please see effort summary and details on what was done:
- LAVA server successfully installed on our Debian Jessie PC
(everything is installed on the same PC machine as explained in the
manual
https://validation.linaro.org/static/docs/installing_on_debian.html#in
stalling-the-full-lava-set )
- Created an administrator(superuser/Local Django Account), as
explained in the manual
https://validation.linaro.org/static/docs/installing_on_debian.html#lo
cal-django-account
- Device was attached to the same PC using serial interface, “cu” was
used to validate direct serial link connection with device (as
explained in manual
https://validation.linaro.org/static/docs/lava-image-creation.html#add
ing-a-device-to-lava )
- Device was added to LAVA dispatcher
a. Created a “sbc8016e.conf” in /etc/lava-dispatcher/devices:Device_type = apq8016-sbcHostname = sbc8016eConnection_command = sg dialout “cu –l /dev/ttyUSB0 –s115200”
That connection command will only be used if the job involves a deploy and a boot. Persistent devices like dummy-ssh will not use the serial connection, just the SSH connection.
- Added a device to the scheduler with the same device type and name of
device as the hostname above. Please fined attached a screenshot “adding device to scheduler”.
- Created a bundle stream. Please fined attached a screenshot “creating a
bundle stream”.
We understood at this point that master image is required and in
normal case LAVA works with U-Boot based ARM devices and creates
special master boot-images and boot devices with it
There is no need for a master image in your case. If the image is already deployed, then you would simply make the connection. In the old dispatcher, this would be a dummy-ssh device type, as long as an SSH server can be installed in the pre-built image. The device would not be powered off between jobs and there are issues with persistence.
https://validation.linaro.org/static/docs/dispatcher-design.html#persistence
It is also possible to "fake" a deploy and boot by passing boot arguments that load the filesystem kernel, dtb and possibly initramfs into memory and then boot those. Between tests, the device would then be powered off. In this method, you wouldn't use the SSH connection, the test would run over the serial connection, using auto-login support if required.
In the pipeline dispatcher, this would be a primary connection using SSH or a uboot deployment.
https://validation.linaro.org/static/docs/dispatcher-design.html#primary-con...
In either case, what you need on the device is simply the bootloader and the image, with configuration to boot the image by default.
We also tried to connect LAVA to device using dummy-ssh connection as described in https://validation.linaro.org/static/docs/deprecated/dummy-deploy.html and https://validation.linaro.org/static/docs/hacking-session.html :
- SSH hacking session - After that we tried to connect via an ssh as a
hacking session. As shown in the manual. Got same results.
A hacking session is interactive - it expects to have an image deployed and booted, then to install something like openssh-server and then for a human to login and run commands.
- Deploying dummy devices – we changed the “sbc8016e.conf” file to a
dummy-SSH configuration as shown in the manual. Please fined attached
“sbc8016e.conf” file with dummy-SSH configuration
a) This is the only thing that gave us log entries (attached “dummy-ssh log entries” screenshot). But it had no connection to our board, we got the same logs with a disconnected board.
I'm not sure what you mean by connection to your board. If you mean the boot logs, then you actually have to boot the device under the control of LAVA to get those - that means running a deploy and a boot.
dummy-ssh expects the device to be permanently powered on, so it never logs anything about the boot. It will, however, log whatever happens over that SSH connection.
The screenshot only indicates that you didn't specify a deploy action and that you are looking at the job summary. The Complete log button will show the full logs and there is also a download link. The one thing you didn't attach is the job definition, so I can't see why the job failed with "missing deploy action".
The log files are much more useful than screenshots, generally.
Could you please help with us with device<->Lava connection setup?
We have device with preinstalled Debian or OpenEmbedded images, as
mentioned before and we just want to execute test (so we need to skip deploy and boot part of the job) if you have please provide detailed "howto" for device setup:
- what need to be installed on device
- how to configure device and server for network (SSH?) or serial port
connection
Could you please also provide links to real yaml test jobs you have
for
- functionality validation (storage/network/USB/display/cameras/...)
- performance validation (jobs that execute benchmarks)
- stability tests
The majority of git.linaro.org consists of real yaml test jobs but to get a specific answer about which ones are current and useful for your own work, you need to get input from the QA team at Linaro. The linaro-validation mailing list is one way to do that. I would suggest starting a separate thread for this question.
--
Neil Williams
=============
neil.williams@linaro.org
linaro-validation@lists.linaro.org
-
Neil Williams