This comics explains the birth of the project
Tunir. When I started working in
the Fedora Cloud SIG, I volunteered myself to help with the testing of the
Cloud images. We have very clear guidelines about what to test, and how to
Basically, you have to boot up a cloud image (or the atomic image) in a Cloud or
on your local computer, run a few commands in sequence, and check the output. For
the first few times it was fun to do, but slowly I found it is difficult for me.
Being a super lazy programmer, I thought why not use the computer to do this
job, it is not music theory :) The birth of Tunir was the result of the
conversation between me and even lazier me. I just had to convert the shell
commands into some Python3 based unittest cases.
At beginning it could only handle the qcow2 images of cloud base and atomic
image. But while working with two week atomic change, I found out that we need
do the same for Vagrant based images. It is important to remember that Fedora
project generates two different kind of Vagrant boxes, one for libvirt,
another one for standard Virtualbox based .box file. So Tunir got the power
to execute tests on any given Vagrant image. Using these features Tunir is
being consumed by the Autocloud project, where we automatically test Fedora
cloud and Atomic image builds. I should not forget to mention that Tunir
can also connect to a remote system, and execute the tests there. Did I
mention that Tunir is doing all of these with only one JSON file containing
the job description, and one text file containing the commands used for the
actual tests? Tunir started as a tool for a developer, who does not want to
spend time in configuration, it remains in the same way.
Until a couple of releases back, Tunir actually had two types of tests in it, one
type of commands which will return zero as a success value, we could also mark
a set of commands as the ones which will return non-zero exit code. Right now
Tunir can have a third set of commands, the non-gating tests, these commands
may pass, or they may fail. But Tunir will continue executing the tests
I wrote Tunir to test the actual OS images, but it is generic enough that it
can be used to test any application. You can easily configure it to download
all the dependencies of your project every time on a clean cloud/Vagrant
image, and then it will build and test your application (or the full
application stack along with configuration files).
Last week I have added a new weapon in Tunir’s arsenal. It can now test using a
given AWS AMI ID. If you run your application on AWS cloud platform, you now
can use Tunir to test it there. This code is in a separate branch, but will be
merged in the master this week. Following the similar style Praveen Kumar
submitted a patch using which Tunir can run tests on an Openstack Cloud. We
will work on it a little bit more before merging it to master branch.
You can view the tests already written for Fedora in this repository. Thanks to
Trishna Guha, and Farhaan
Bukhsh we now have many more test cases.
I have written a
explaining how to write more tests, I have another document which explains how
to debug failed tests.
What is in the future? The best way to predict your future is to create it. We
have the features which we, and our users use regularly. Tunir is still simple
enough for anyone to understand in less than 10 minutes. If you just want to
say hi, or you are looking forward for any new feature, come to #fedora-cloud