05d3ff4f5a
When zuul executes jobs it adds all the post plays together and executes them in the inherited sequence. This is causing some confusion in our cross-repo testing where the logs are trying to be collected twice as the cross-repo test is based on the standard functional test. Instead of defining two sets of plays we can consolidate them into a single set, eliminating the confusion and repetition. At the same time we also do not try to collect logs if the script to prepare them was not able to execute, and we fix the conditional for the ARA report generation so that it works properly with the value being given it by zuul which is a boolean word. To make sure it still works outside of Zuul we leave the conditional which uses the standard success return code of 0. Change-Id: Id5027415f33a7a41650332a983cb87fab7ba2a4a |
||
---|---|---|
ansible-lint | ||
common-tasks | ||
doc | ||
network_interfaces | ||
releasenotes | ||
tests | ||
zuul.d | ||
.gitignore | ||
.gitreview | ||
bindep.txt | ||
create-grant-db.yml | ||
destroy_containers.yml | ||
ensure-rabbitmq.yml | ||
gen-projects-list.sh | ||
get-ansible-role-requirements.yml | ||
iptables-clear.sh | ||
LICENSE | ||
manual-test.rc | ||
README.rst | ||
run_tests_common.sh | ||
run_tests.sh | ||
setting-nodepool-variables.yml | ||
setup.cfg | ||
setup.py | ||
sync-test-repos.sh | ||
test-ansible-deps.txt | ||
test-ansible-env-prep.sh | ||
test-ansible-functional.sh | ||
test-ansible-lint.sh | ||
test-ansible-syntax.sh | ||
test-ansible.cfg | ||
test-bashate.sh | ||
test-install-cinder.yml | ||
test-install-etcd.yml | ||
test-install-galera.yml | ||
test-install-glance.yml | ||
test-install-gnocchi.yml | ||
test-install-haproxy.yml | ||
test-install-heat.yml | ||
test-install-horizon.yml | ||
test-install-infra.yml | ||
test-install-ironic.yml | ||
test-install-keystone.yml | ||
test-install-memcached.yml | ||
test-install-neutron.yml | ||
test-install-nova.yml | ||
test-install-openstack-hosts.yml | ||
test-install-rabbitmq.yml | ||
test-install-sahara.yml | ||
test-install-swift.yml | ||
test-install-tempest.yml | ||
test-log-collect.sh | ||
test-pep8.sh | ||
test-prepare-containers.yml | ||
test-prepare-host.yml | ||
test-prepare-keys.yml | ||
test-repo-setup.yml | ||
test-requirements.txt | ||
test-setup-cinder-localhost.yml | ||
test-setup-host.yml | ||
test-setup-swifthosts.yml | ||
test-vars.yml | ||
tox.ini | ||
Vagrantfile |
Team and repository tags
OpenStack-Ansible testing
This is the openstack-ansible-tests
repository,
providing a framework and consolidation of testing configuration and
playbooks. This can be used to integrate new projects, and ensure that
code duplication is minimized whilst allowing the addition of new
testing scenarios with greater ease.
Role Integration
To enable the openstack-ansible-tests
repository, ensure
that the tox.ini
configuration in the role repository
matches the galera_client
repository tox.ini with the exception of the value for
ROLE_NAME
. A more advanced configuration which implements
multiple functional test scenarios is available in the neutron
role tox.ini.
To override variables you can create a
${rolename}-overrides.yml
file inside the role's tests
folder. This variable file can be includes in the functional tox target
configuration in tox.ini
as demonstrated in the following
extract:
ansible-playbook -i {toxinidir}/tests/inventory \
-e @{toxinidir}/tests/${rolename}-overrides.yml \
-vvvv {toxinidir}/tests/test.yml
In your repositories tests/test.yml
file, you can call
any of the included playbooks, for example:
- include: common/test-prepare-keys.yml
Network Settings
The networking can be configured and setup using the
bridges
variable.
The base option, when only 1 interface is required is to specify just
a single base - this is only for backwards compatibility with existing
test setup and will default to br-mgmt
with an IP of
10.1.0.1
.
bridges:
- "br-mgmt"
To allow a more complicated network setup we can specify
ip_addr
: The IP address on the interface.
netmask
: Netmask of the interface (defaults to
255.255.255.0) name
: Name of the interface
veth_peer
: Set up a veth peer for the interface
alias
: Add an alias IP address
For example, a Nova setup may look like this:
bridges:
- name: "br-mgmt"
ip_addr: "10.1.0.1"
- name: "br-vxlan"
ip_addr: "10.1.1.1"
- name: "br-vlan"
ip_addr: "10.1.2.200"
veth_peer: "eth12"
alias: "10.1.2.1"