Detailed description of the tests

The jobname.txt text file contains the bash commands to run in the system, one command per line. In case you are rebooting the system, you may want to use SLEEP NUMBER_OF_SECONDS directive there.

If a command starts with @@ sign, it means the command is supposed to fail. Generally, we check the return codes of the commands to find if it failed, or not. For Docker container-based systems, we track the stderr output.

We can also have non-gating tests, means these tests can pass or fail, but the whole job status will depend on other gating tests. Any command in jobname.txt starting with ## sign will mark the test as non-gating.

Example:

## curl -O https://kushal.fedorapeople.org/tunirtests.tar.gz
ls /
## foobar
## ls /root
##  sudo ls /root
date
@@ sudo reboot
SLEEP 40
ls /etc

Polling the VM(s)

We can use the POLL directive in the jobfile after a reboot, this will try to POLL every VM to make sure that we have the SSH service back in all the VM((s).

Example:

ls
@@ sudo reboot
POLL
ls /

Coping files over

gotun can copy files over to any VM using scp. The following is an example where we are copying a binary file into bin directory inside home of the user on vm1.

COPY: localfile.bin vm1:./bin/

Multiple VM based tests

In case of tests containing multiple VM(s), one mark the tests with vm numbers. This way, we decide which test will run on which vm. The numbers start from vm1 to vm9.

Example:

vm1 wget https://kushaldas.in
vm2 sudo mkdir /root/hello_dir
vm1 sudo dnf install pss -y
vm1 which pss

If no vm number is marked at the begining of any line, gotun assumes that the test is supposed to run on vm1.

Rebuild of VM(s) on OpenStack

Note

This feature is only available for OpenStack based jobs. For other kind of tests, this will do nothing.

REBUILD_SERVERS directive will rebuild all of the avialable VM(s) on OpenStack. They will try to POLL the VM(s) after rebuilding them. This step is sequential for now. In future, we will be doing this in parallal.

echo "hello asd" > ./hello.txt
vm1 sudo cat /etc/machine-id
mkdir {push,pull}
ls -l ./
pwd
REBUILD_SERVERS
sudo cat /etc/machine-id
ls -l ./
pwd

The following is the output from the above mentioned test.

$ gotun --job fedora
Starts a new Tunir Job.

Server ID: e0d7b55a-f066-4ff8-923c-582f3c9be29b
Let us wait for the server to be in running state.
Time to assign a floating pointip.
Polling for a successful ssh connection.

Polling for a successful ssh connection.

Polling for a successful ssh connection.

Polling for a successful ssh connection.

Polling for a successful ssh connection.

Polling for a successful ssh connection.

Polling for a successful ssh connection.

Polling for a successful ssh connection.

Server ID: a0b810e6-0d7f-4c9e-bc4d-1e62b082673d
Let us wait for the server to be in running state.
Time to assign a floating pointip.
Polling for a successful ssh connection.

Polling for a successful ssh connection.

Polling for a successful ssh connection.

Polling for a successful ssh connection.

Polling for a successful ssh connection.

Polling for a successful ssh connection.

Executing:  echo "hello asd" > ./hello.txt
Executing:  vm1 sudo cat /etc/machine-id
Executing:  mkdir {push,pull}
Executing:  ls -l ./
Executing:  pwd
Going to rebuild: 209.132.184.241
Polling for a successful ssh connection.

Polling for a successful ssh connection.

Polling for a successful ssh connection.

Polling for a successful ssh connection.

Polling for a successful ssh connection.

Going to rebuild: 209.132.184.242
Polling for a successful ssh connection.

Polling for a successful ssh connection.

Polling for a successful ssh connection.

Polling for a successful ssh connection.

Polling for a successful ssh connection.

Executing:  sudo cat /etc/machine-id
Executing:  ls -l ./
Executing:  pwd

Result file at: /tmp/tunirresult_180507156


Job status: true


command: echo "hello asd" > ./hello.txt
status:true



command: sudo cat /etc/machine-id
status:true

e0d7b55af0664ff8923c582f3c9be29b


command: mkdir {push,pull}
status:true



command: ls -l ./
status:true

total 4
-rw-rw-r--. 1 fedora fedora 10 Jan 25 13:58 hello.txt
drwxrwxr-x. 2 fedora fedora  6 Jan 25 13:58 pull
drwxrwxr-x. 2 fedora fedora  6 Jan 25 13:58 push


command: pwd
status:true

/var/home/fedora


command: sudo cat /etc/machine-id
status:true

e0d7b55af0664ff8923c582f3c9be29b


command: ls -l ./
status:true

total 0


command: pwd
status:true

/var/home/fedora


Total Number of Tests:8
Total NonGating Tests:0
Total Failed Non Gating Tests:0

Success.

Creating inventory file for Ansible based tests

Ansible is a powerful choice with many different usecases. One such usecase is about testing. Sometimes we just setup the whole test environment using Ansible, and some other times the whole testsuite is written on top of ansible. To enable using of predefined Ansible playbooks, gotun provides a file current_run_info.json for each run of job. This file contains a dictionary of vm numbers, and corresponding IP address, and also the keyfile value with the path of the private keyfile. This can be used with a simple Python or shell script to create the actual inventory file. For example, the following script createinventory.py will create a file called inventory in the current directory, and it assumes that there will be 2 VM(s) are avaiable (means it is running on OpenStack).

#!/usr/bin/env python3
import json

data = None
with open("current_run_info.json") as fobj:
    data = json.loads(fobj.read())

user = data['user']
host1 = data['vm1']
host2 = data['vm2']
key = data['keyfile']

result = """{0} ansible_ssh_host={1} ansible_ssh_user={2} ansible_ssh_private_key_file={3}
{4} ansible_ssh_host={5} ansible_ssh_user={6} ansible_ssh_private_key_file={7}""".format(host1,host1,user,key,host2,host2,user,key)
with open("inventory", "w") as fobj:
    fobj.write(result)

As you can see, we are reading the current_run_info.json file first, and then creating a file called inventory. We can then execute this script by using the HOSTCOMMAND directive in the test.

HOSTCOMMAND: ./createinventory.py

Running Ansible on the HOST as part of a test

The next step is to run Ansible playbook on the host system as a test. This can be done with a HOSTTEST directive. The following example test file will first create the inventory file using a HOSTCOMMAND directive, and then execute the an ansible playbook.

HOSTCOMMAND: ./onevm.py
HOSTTEST: ansible-playbook -b -i inventory atomic-host-tests/tests/improved-sanity-test/main.yml