The repository contains several helper scripts to manage gate jobs, install base requirements, and update repository information. Execute these scripts from the root of the repository clone. For example:
$ scripts/<script_name>.sh
The bootstrap-ansible.sh
script installs Ansible including core and
extras module repositories and Galaxy roles.
While there are several configurable environment variables which this script uses, the following are commonly used:
ANSIBLE_PACKAGE
- The version of Ansible to install.For example:
$ export ANSIBLE_PACKAGE="ansible==2.1.0"
Installing directly from git is also supported. For example, from the tip of Ansible development branch:
$ export ANSIBLE_PACKAGE="git+https://github.com/ansible/ansible@devel#egg=ansible"
ANSIBLE_ROLE_FILE
- The location of a YAML file which ansible-galaxy can
consume which specifies which roles to download and install. The default
value for this is ansible-role-requirements.yml
.The script also creates the openstack-ansible
wrapper tool that provides
the variable files to match /etc/openstack_deploy/user_*.yml
as
arguments to ansible-playbook
as a convenience.
The bootstrap-aio.sh
script prepares a host for an All-In-One (AIO)
deployment for the purposes of development and gating. The script creates the
necessary partitions, directories, and configurations. The script can be
configured using environment variables - more details are provided on the
All-In-One page.
The run-playbooks
script is designed to be executed in development and
test environments and is also used for automated testing. It executes actions
which are definitely not suitable for production environments and must
therefore not be used for that purpose.
The default MaxSessions setting for the OpenSSH Daemon is 10. Each Ansible
fork makes use of a Session. By default Ansible sets the number of forks to 5,
but the run-playbooks.sh
script sets the number of forks used based on the
number of CPU’s on the deployment host up to a maximum of 10.
If a developer wishes to increase the number of forks used when using this script, override the ANSIBLE_FORKS environment variable. For example:
export ANSIBLE_FORKS=20
Python coding conventions are tested using PEP8, with the following convention exceptions:
Testing may be done locally by executing:
tox -e pep8
Bash coding conventions are tested using Bashate, with the following convention exceptions:
Testing may be done locally by executing:
tox -e bashate
Ansible is lint tested using ansible-lint.
Testing may be done locally by executing:
tox -e ansible-lint
Ansible playbook syntax is tested using ansible-playbook.
Testing may be done locally by executing:
tox -e ansible-syntax
A consolidated set of all lint tests may be done locally by executing:
tox -e linters
Documentation is developed in reStructuredText (RST) and compiled into HTML using Sphinx.
Documentation may be built locally by executing:
tox -e docs
tox -e deploy-guide
Release notes are generated using the the reno tool and compiled into HTML using Sphinx.
Release notes may be built locally by executing:
tox -e releasenotes
Note
The releasenotes
build argument only tests committed changes.
Ensure your local changes are committed before running the
releasenotes
build.
Every commit to the OpenStack-Ansible integrated build is verified by OpenStack-CI through the following jobs:
gate-openstack-ansible-releasenotes
: This job executes the
Release Notes Build.
gate-openstack-ansible-docs-ubuntu-xenial
: This job executes the
Documentation Build.
gate-openstack-ansible-linters-ubuntu-xenial
: This job executes
the Lint Tests.
gate-openstack-ansible-openstack-ansible-aio-ubuntu-xenial
: where
aio
is the scenario, ubuntu
is the distribution, and xenial
is the version of the distribution.
The same test is executed against multiple distribution versions, and may be executed against multiple distributions and multiple scenarios too.
This job executes the gate-check-commit.sh
script which executes a
convergence test and then a functional test.
The convergence test is the execution of an AIO build which aims to test the primary code path for a functional environment. The functional test then executes OpenStack’s Tempest testing suite to verify that the environment that has deployed successfully actually works.
While this script is primarily developed and maintained for use in OpenStack-CI, it can be used in other environments.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.