On 9 February 2018 at 13:01, Zoran S <zoran.stojsavljevic.de@gmail.com> wrote:

Hello Neil,

Please, hold your horses. I am very new to all this, and I need some
time to get to the Lava architecture, meaning to get in proper ways.

OK. We have tried to make the documentation as friendly as possible for this situation.

I reference the staging.validation.linaro.org docs here but you can adapt the URLs to localhost to read docs for your exact version of LAVA.

I've replied to your questions inline but it sounds as if you will find things easier to understand by ignoring the BBB work for now, follow the docs on setting up a QEMU device, submit the example first job from the documentation to run a x86_64 QEMU image inside LAVA and get that working. This will help with concepts like device-type templates and device dictionaries, device configuration and device creation. You can do all that, using LAVA V2, using the version of LAVA you already have installed.

0: The QEMU steps:

https://staging.validation.linaro.org/static/docs/v2/first-devices.html#adding-a-dictionary-to-the-first-qemu-device

https://staging.validation.linaro.org/static/docs/v2/pipeline-admin.html#create-device-dictionary

(Hint: as this is your local instance, just create the file in /etc/lava-server/dispatcher-config/devices/ as in the very last paragraph in that section.)

https://staging.validation.linaro.org/static/docs/v2/first-job.html

https://staging.validation.linaro.org/static/docs/v2/explain_first_job.html#explain-first-job

Then come back to:

1: The upgrade steps,

2: configuring the PDU

3: configuring ser2net

4: the use of BBB using the example images,

5: finally move on to using your own images with the BBB.

In the sense, I'll try to rephrase the questions, and the working
context, since your answers make me more confused than bring the
viable solutions... :-(

After reading your email, there are the major addendums to this
context, so let me rephrase/rework my initial email.
_______

My aim is to use Lava V2 (since Lava V1 is not supported anymore). Let it be.

As I mentioned, I would like to use Beagle Bone Black (BBB) to Lava
worker, and from Lava apache to set the proper context for testing BBB
HW.

But also, for the starters (seems the step in between) I can do QEMU
(the problem is I have no idea how to do this outside of YOCTO
Project).

There are example jobs in the LAVA documentation for QEMU. It is an ideal place to learn how a LAVA Test Shell works and what can be done. Having said that, your test shell definitions should aim to be portable. This means checking for the lava helpers in the $PATH and using them or using echo or logging etc if not. This allows you to create the scripts which run inside your test outside LAVA and use exactly the same scripts inside. All of this can be developed in QEMU.

We provide examples of the device dictionary, instructions on creating the device(s) for QEMU, example test jobs and permanent locations for the images to use in the test jobs on QEMU devices. All these images have been tested and continue to be tested regularly.

> What version of LAVA are you running? On Debian Jessie or Debian Stretch?

I am running Lava v2017/7. Which supports ONLY V1. On Virtual Machine
Debian Stretch (using VBox as VMM).

2017.7 supports V2. All releases after 2017.2 have usable V2 support.

V1 uses JSON test job submissions, V2 uses YAML test job submissions.

Check the Help menu on your instance - the V2 documentation is available alongside V1.

Also check the documentation on LAVA repositories - those provide the way to upgrade stretch to the latest release, 2018.2

Don't confuse LAVA V2 with Python2 / Python3 support. LAVA V2 is also called "pipeline" and various parts of the UI refer to pipeline support.

root@stretch:/home/vagrant# uname -a
Linux stretch 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3 (2017-12-03) x86_64 GNU/Linux
root@stretch:/home/vagrant# dpkg-query -W -f '${version}\n' 'lava-server'
2017.07

I'm not sure how that was setup, the version available for stretch is in stretch-backports: https://packages.debian.org/source/stretch-backports/lava-dispatcher and https://packages.debian.org/source/stretch-backports/lava-server

2017.7-1~bpo9+1

My problem here is that I can build the newest version of the
Hashicorp debian/stretch64 using vagrant:
https://app.vagrantup.com/debian/boxes/stretch64

But I am NOT able to include the newest Lava into this setup, since
apt-get install Lava (and components) is bringing me Lava V1 (even
very old version 2016.12-2)???

https://staging.validation.linaro.org/static/docs/v2/installing_on_debian.html#lava-repositories

Most of the LAVA instances are running the latest code on Stretch.

Q1: how I can bring here the newest Lava 2018.01 (only Version 2
compliant)? What the apt-get install Lava-2018.01 or similar command
(I am Fedora monkey, as considering my host setup. Lava I am
bringing/installing into the VM over VBox VMM)?

Create an apt source for:

deb https://images.validation.linaro.org/production-repo stretch-backports main

(Create a file in /etc/apt/sources.list.d/ called lava.list or similar with this lne - just make sure the filename ends in .list - then run apt update)

In other words, what is the specific command I need to use in scripts
to bring proper Lava 2018.01??? Or any another command?
Here is what is now used: sudo DEBIAN_FRONTEND=noninteractive apt-get
-y install lava -t stretch-backports

stretch-backports has 2017.7-1~bpo9+1

You should follow the documentation and add the LAVA repositories if you want to get 2018.2

However, for your needs, 2017.7-1~bpo9+1 will be fine for your V2 development at this time and you can do the upgrade later.

> Jinja is V2 - so things are already getting confused. You can use the U-Boot
> that comes with the BBB but you will need to account for any changes in
> prompts etc. in the device configuration.

I already use the newest 2017.11 BBB U-Boot, so anyway I need to tap
(and change some strings) into the following files (as of my best
understanding):
root@stretch:/# find . -name base-uboot.jinja2
./etc/lava-server/dispatcher-config/device-types/base-uboot.jinja2
root@stretch:/# find . -name beaglebone-black.jinja2
./etc/lava-server/dispatcher-config/device-types/beaglebone-black.jinja2
root@stretch:/# find . -name qemu.jinja2
./etc/lava-server/dispatcher-config/device-types/qemu.jinja2
root@stretch:/#

The device-types don't need to be changed at this point. All you need to do is create the devices in the database and create a device dictionary - a set of commands which extend the device-type template into a configuration for a single device.

https://staging.validation.linaro.org/static/docs/v2/first-devices.html

https://staging.validation.linaro.org/static/docs/v2/first-devices.html#adding-a-dictionary-to-the-first-qemu-device

Q2: I need here some examples, if they exist. How I can build these
scripts, or should I use existing? Or to do something more to hook
Lava to ser2net?

https://staging.validation.linaro.org/static/docs/v2/first-devices.html#check-existing-instances

ser2net exposes a telnet port on a hostname. The connection_command is then set in the device dictionary. LAVA then calls telnet which opens the serial connection using the ser2net service.

I already know: interrupt_prompt: {{ interrupt_prompt|default('Hit any
key to stop autoboot') }} <<===== String MUST be changed for U-Boot
2017.11!

That's an unusual build of U-Boot which changes the Hit any key interrupt prompt. If there is no prompt, you should set bootdelay to 10 so that you get the prompt to interrupt.

In your case, your device dictionary would contain (amongst other lines) a line like:

{% set interrupt_prompt = "Hit any key" %}

or whatever your interrupt prompt is.

Note: this isn't the same as the bootloader prompt (which could be U-Boot => or just => or similar) - that appears after the interrupt string.

This is a recent working test job on a BBB which shows the output: https://staging.validation.linaro.org/scheduler/job/209986

You can see the device dictionary here: https://git.linaro.org/lava/lava-lab.git/tree/staging.validation.linaro.org/master-configs/staging-master.lavalab/lava-server/dispatcher-config/devices/staging-black01.jinja2 (that uses some features from 2018.2, it's just an example.)

Q3: I see that base-uboot.jinja2 is a base file. Should I include it
it other .jinja2 files using:
{% extends 'base-uboot.jinja2' %}

That is a step you do later when you add a new device-type.

For your device dictionary you need:

{% extends 'beaglebone-black.jinja2' %}

{% set connection_command = 'telnet localhost 7105' %}

{% set hard_reset_command = '/usr/local/lab-scripts/snmp_pdu_control --hostname pdu15 --command reboot --port 15' %}

{% set power_off_command = '/usr/local/lab-scripts/snmp_pdu_control --hostname pdu15 --command off --port 15' %}

{% set power_on_command = '/usr/local/lab-scripts/snmp_pdu_control --hostname pdu15 --command on --port 15' %}

(The last three lines are the PDU commands - yours will be quite different and you'll also need to change the port number according to how you've configured ser2net.)

> That looks like you have to manage the power control using
> a graphical interface and that's not going to work...

Let us skip for now this question (I would like to simplify). PDU is
for now not of importance. Focusing to make minimalistic approach to
work.

PDU will required to get the BBB to work but not the QEMU. So stick to QEMU and the device-dictionary in the example to start with.

QEMU is much simpler as a device dictionary:

{% extends 'qemu.jinja2' %}

{% set mac_addr = '52:54:00:12:34:59' %}

{% set memory = '1024' %}

> That will show up in /dev/serial/by-id/ and that becomes part of the ser2net configuration.

The whole ttyUSB0 using ser2net TCP is done already, works like a
charm. In VM, as pass-through device.

Q4: do I need to use something special here to hook ser2net terminal to Lava?

root@stretch:/# cd /dev/serial
root@stretch:/dev/serial# ls -al
total 0
drwxr-xr-x 4 root root 80 Feb 9 11:29 .
drwxr-xr-x 19 root root 3140 Feb 9 11:32 ..
drwxr-xr-x 2 root root 60 Feb 9 11:29 by-id
drwxr-xr-x 2 root root 60 Feb 9 11:29 by-path
root@stretch:/dev/serial#

You need to configure ser2net with a line something like:

6007:telnet:0:/dev/serial/by-id/usb-FTDI_TTL232R-3V3_FTGNVQS6-if00-port0:115200 8DATABITS NONE 1STOPBIT banner LOCAL

That would then mean you run telnet localhost 6007 to connect to the ser2net service which provides access to that serial connection.

When you change the ser2net configuration (/etc/ser2net.conf) you need to tell the service to update:

sudo service ser2net reload

> That is all managed by LAVA in the test job submission. TFTP is already configured.

in.tftp works like a charm (tftp-ing from VM to U-Boot BBB), as well
as dhcpd (dnsmasq, also from VM). So, I have to trust you if you say
that I do not need to do anything on that.

> Typically, for the BBB, we use the mainline U-Boot that comes from Debian.
> https://packages.debian.org/stretch/u-boot-omap

In fact, this was not my question (I have latest 2017.11 U-Boot there
on mmcblk1 which is /boot partition, works perfectly).

OK. The extra little hurdle with that version is that it requires changing the prompts from the defaults.

{% set interrupt_prompt = "Hit any key" %}

or whatever your interrupt prompt is.

Q5: I wanted to know do I need to set up U-Boot scripts in some ways
(as /etc/lava-server/dispatcher-config/device-types/beaglebone-black.jinja2
suggests, as example)??? In other words, make U-Boot environment more
as .jinja2 suggests?

You set the overrides in the device dictionary for the device, not the device-type.

/etc/lava-server/dispatcher-config/devices/

Create the device dictionary there, using a filename which matches the name of the device in the database. e.g. bbb-01 would have a file bbb-01.jinja2

A lot of this will be easier to understand if you setup your first QEMU device by following the documentation step by step.

> Start with QEMU, make sure that's working and get an understanding of how that works with the device dictionary, test job submission, test shell definitions and general LAVA UI usage.

Q6: So, what I need to do here? I use YOCTO project to build all BBB
embedded Linux ingredients, uImage, .dtb and root tree, how I can use
QEMU from YOCTO as independent .exe in Lava context??? Or, maybe,
after all, I can try real image?!

The reason BBB is recommended is because LAVA has example test jobs which use standard test images which are tested daily:

https://staging.validation.linaro.org/static/docs/v2/standard-test-jobs.html

https://staging.validation.linaro.org/static/docs/v2/standard-qemu-jessie.html

https://staging.validation.linaro.org/static/docs/v2/standard-armmp-ramdisk-bbb.html

https://staging.validation.linaro.org/static/docs/v2/examples/test-jobs/standard-armmp-ramdisk-bbb.yaml

http://images.validation.linaro.org/snapshots.linaro.org/components/lava/standard/debian/jessie/armhf/4/

Once you have those working, you can try your own images - i.e. change one thing at a time. Get things working with known working images so that you know that your PDU, ser2net and network infrastructure is working correctly before you add the extra step of your own images.

You wouldn't use a QEMU executable from Yocto, QEMU is installed by lava-dispatcher and will be used at that version. There are example image files to use with QEMU in LAVA, you don't need to build any yourself, at least initially. Start with x86_64 images to make things easier.

I apologize for the long email. Some features are already solved
(tftp, edhcp, ser2net), so we do not need to include them further (as
I now understand).

Thank you,
Zoran
_______

On Fri, Feb 9, 2018 at 10:23 AM, Neil Williams <neil.williams@linaro.org> wrote:
> On 9 February 2018 at 09:00, Zoran S <zoran.stojsavljevic.de@gmail.com>
> wrote:
>>
>> Hello to the Lava users,
>>
>> I am the new Lava user. My aim is to use Lava (for now V1)
>
>
> Welcome. Please take care with terminology. V1 is already dead, please don't
> start there. We will be unable to help you with your V1 setup. Your later
> comments refer to elements from V2, so please take care with which bits of
> documentation you are following.
>
> What version of LAVA are you running? On Debian Jessie or Debian Stretch?
>
>>
>> setup for my testing, from the beginning just to hook-up my Beagle Bone
>> Black (BBB) to Lava worker, and from Lava apache to set the proper context
>> for testing BBB HW.
>>
>> As I am reading Lava framework, I got the following impression about the
>> test suite:
>> [1] I need to prepare BBB's U-Boot for the Lava U-Boot jinja2 setup;
>
>
> Jinja is V2 - so things are already getting confused. You can use the U-Boot
> that comes with the BBB but you will need to account for any changes in
> prompts etc. in the device configuration.
>
>>
>> [2] I need to hook-up my EG-PMS2-LAN (energenie) to the Lava (to PO and
>> POFF HW platform);
>
>
> That looks like you have to manage the power control using a graphical
> interface and that's not going to work. You'll need to investigate how to
> control that unit using the command line only. Does it have a telnet API or
> other serial API? That will all be down to you to configure. You might want
> to look at using an APC PDU instead as those already have support in lavapdu
> (or can use SNMP if you configure the worker appropriately).
>
> [3] I need to hook-up ser2net interface (which I already have working over
> TCP) to the Lava. so Lava can control it;
>
> That goes into the device dictionary, as per the docs. Do you have the FTDI
> cable to attach to the BBB to get the serial connection? That will show up
> in /dev/serial/by-id/ and that becomes part of the ser2net configuration.
>
>>
>> [4] I need to hook-up uImage, .dtb and ramdisk images to the Lava (which
>> will be FTPed and set in memory for board setup and testing).
>
>
> TFTP, not FTP.
>
> That is all managed by LAVA in the test job submission. TFTP is already
> configured.
>
>>
>>
>> Question 1: Does manual have some Beagle Bone Black U-Boot default
>> scripts, which should be provisioned to the BBB U-Boot for the correct Lava
>> U-Boot behavior?
>
>
> Typically, for the BBB, we use the mainline U-Boot that comes from Debian.
> https://packages.debian.org/stretch/u-boot-omap
>
>>
>> Question 2: How do I do [1], [2], [3] and [4], does Lava manual have some
>> explanation as working example how to do these points?
>
>
> Those are mostly specific to your local setup.
>
>>
>> Question 3: Anything else I missed for the proper Lava test setting?
>
>
> Start with QEMU, make sure that's working and get an understanding of how
> that works with the device dictionary, test job submission, test shell
> definitions and general LAVA UI usage.
>
>>
>>
>> Thank you in advance,
>> Zoran
>>
>>
>> _______________________________________________
>> Lava-users mailing list
>> Lava-users@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lava-users
>>
>
>
>
> --
>
> Neil Williams
> =============
> neil.williams@linaro.org
> http://www.linux.codehelp.co.uk/

Neil Williams
=============
neil.williams@linaro.org
http://www.linux.codehelp.co.uk/