Place to store data required to build up a CI for any Fuel plugin
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
OpenDev Sysadmins b1832986ff OpenDev Migration Patch 1 month ago
hardware-configuration add hardware authentication via expect example 3 years ago
iso-updater fix 3 years ago
jjb add publish logs job 3 years ago
pics Provides changes for documentation 3 years ago
plugin-test-examples/plugin_test Clean up Readme.rst and test exmaples 3 years ago
puppet-manifests add ssh puppet module 3 years ago
.gitmodules add plugin tests example 3 years ago
.gitreview OpenDev Migration Patch 1 month ago
README.rst Clean up Readme.rst and test exmaples 3 years ago


Fuel Plugin CI


Components, concept


Jenkins and web server for logs installation

First you should install puppet master and run the manifests.

All nodes described in manifests/site.pp file.

CI needs the following amount of nodes:

  • one node for jenkins master
  • one more for jenkins slave
  • one for log publication.

These nodes should be described in manifests/site.pp with necessary classes:

class { '::fuel_project::jenkins::slave':}
class { '::fuel_project::jenkins::master':}
class { '::fuel_project::web':}

Run install script sudo puppet-manifests/bin/ on every node.

Gerrit Integration overview

In general, the installation should meet the following requirements:

  • Anonymous users can read all projects.
  • All registered users can perform informational code review (+/-1) on any project.
  • Jenkins can perform verification (blocking or approving: +/-1).
  • All registered users can create changes.
  • Members of core group can perform full code review (blocking or approving: +/- 2) and submit changes to be merged.
  • Make sure you have gerrit account on (see this for the reference):

    ssh -p 29418 "gerrit create-account \
         --group 'Third-Party CI' \
         --full-name 'Some CI Bot' \
         --email \
         --ssh-key 'ssh-rsa AAAAB3Nz...zaUCse1P' \

Jenkins gerrit plugin configuration

  1. The settings look as follows:


  2. It's main gerrit configuration window. You should add a gerrit server.


  3. Vote configuration.
  4. Log publication The result of job are artifacts - logs and packages. Logs should be published on special web servers, where it can be accessible via gerrit. The web server deploys with puppet class fuel_project::web.

Logs copy via ssh by job fuel-plugins.publish_logs. You should add new user with rsa key installed and necessary path accessible for write (like /var/www/logs).

The REPORTED_JOB_URL variable is responsible for url of logs in gerrit.

Jenkins plugins installation

We recommend to install these plugins for Jenkins. Some of them are necessary for CI and other is just useful and make your jenkins experience easier:

Jenkins jobs installation

Jenkins Job Builder takes simple descriptions of Jenkins jobs in YAML or JSON format and uses them to configure Jenkins.

To install JJB, run the following commands:

git clone
cd jenkins-job-builder && sudo python install

Before running JJB you need to prepare a config file with the following info (fill it with your own values):


And update a JJB configuration using the file from the previous step:

jenkins-jobs --conf yourconf.ini update path_to_repo/jjb

You may find some examples in this repo. They're depersonalized copies of real jobs, so don’t install them without reworking. Please replace necessary paths and variables to make them work again.

Plugin test templates

Most of necessary functions can be found in fuel-qa framework.

All functional tests should be stored in ` plugin’s git repository in a special folder named plugin_test. Fuel-qa framework should be submodule in the plugin_test folder. You can add submodule by this command:

git submodule add


In the folder ./plugin-test-examples/plugin_test you may find two simple tests. The first one installs a test plugin, creates a cluster and enables the plugin for this cluster. The second one deploys a cluster with the plugin enabled.

There are two subfolders here: helpers and tests. Helpers contains two files with important functions: * prepare_test_plugin - installs the plugin to master node * activate_plugin - activates the plugin * assign_net_provider - allows to choose network type for cluster * deploy_cluster - deploys a cluster

The next folder includes tests. In the example provided with this repo there is only one important file named It describes a class TestPlugin and 2 tests mentioned earlier.

Hardware test examples

The main problem of hardware configuration is authorization. SSH does not allow to enter a password in a script non interactively, so expect utility may be used to avoid the problem.

You should install the util on jenkins-slave first:

apt-get install expect

Here is an example of a script that uses expect for auth on a switch and shows its configuration:

spawn ssh "root@$switch_ip"
set timeout 500
expect "yes/no" {
send "yes\r"
expect "*?assword" { send "$switch_pass\r" }
} "*?assword" { send "$switch_pass\r" }
expect "# " { send "show run" }
expect "# " { send "exit\r" }

Fuel ISO updating

There is a script fuel-plugin-ci/iso-updater/

It should be added to cron and executed every 2-3 hours.

This script checks for a new community build of Fuel and if there is a new version available, it downloads such. You can run the script on a jenkins-slave node or any web server if you have many slave nodes. Here is how the script works:

  1. Check for the latest community iso. Check the url using the w3m utility and chooses the right tab:
    • the first tab is 8.0 now, so it needs the 2nd tab with Fuel 7.0.
    • Then it parses the tab and gets a Fuel release string.


      if new Fuel version is available, you should fix the script and change a tab number. Also output may change between linux distros and last cut field may change.

  2. Download torrent file from via aria2 console torrent client.
  3. Check for errors and delete folder if there is an error.
  4. Sync downloaded iso with a jenkins slave. You should have necessary users with rsa keys set.