Gotun is a written from scratch golang port of Tunir. Gotun can execute tests on remote systems, or it can run tests on OpenStack and AWS.
Installation from git
If you have a working golang setup, then you can use the standard go get command to install the latest version of gotun.
$ go get github.com/kushaldas/gotun
Configure based on YAML files
Gotun expects job configuration in a YAML file. The following is an example of a job for OpenStack.
---
BACKEND: "openstack"
NUMBER: 3
OS_AUTH_URL: "URL"
OS_TENANT_ID: "Your tenant id"
OS_USERNAME: "USERNAME"
OS_PASSWORD: "PASSWORD"
OS_REGION_NAME: "RegionOne"
OS_IMAGE: "Fedora-Atomic-24-20161031.0.x86_64.qcow2"
OS_FLAVOR: "m1.medium"
OS_SECURITY_GROUPS:
- "group1"
- "default"
OS_NETWORK: "NETWORK_POOL_ID"
OS_FLOATING_POOL: "POOL_NAME"
OS_KEYPAIR: "KEYPAIR NAME"
key: "Full path to the private key (.pem file)"
You can also point the OS_IMAGE to a local qcow2 image, which then will be uploaded to the cloud, and used. After the job is done, the image will be removed.
Multiple VM cluster on OpenStack
The OpenStack based jobs also support multiple VM(s). In the above example, we are actually creating three instances from the image mentioned.
Job file syntax
Gotun supports the same syntax of the actual tests of Tunir. Any line starting with ## means those are non-gating tests, even if they fail, the job will continue. For a cluster based job, use vm1, vm2 and similar numbers to mark which VM to be used for the command.
Rebuild of the instances on OpenStack
For OpenStack based jobs, gotun adds a new directive, REBUILD_SERVERS, which will rebuild all the instances. In case one of your tests does something destructive to any instance, using this new directive you can now rebuild all the instances, and start from scratch. The following is the tests file and output from one such job.
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
$ 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.
Using Ansible inside a job is now easier
Before running any actual test command, gotun creates a file called current_run_info.json in the job directory, we can now use that to create inventory file for Ansible. Then we can mark any Ansible playbook as a proper test in the job description.
#!/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)
The above-mentioned script is an example, we are reading the JSON file created by the gotun, and then writing to a new inventory file to be used by an Ansible playbook. The documentation has one example of running atomic-host-tests inside gotun.
You have any question, come and ask in the #fedora-cloud channel. You can contact me over twitter too.