f89e9f031e
When a patch is submitted against a branch, Zuul CI will collect job variants for each ci job and all its parent jobs. If both job.\ override-checkout and job.required-projects.override-checkout attributes are not defined, then Zuul will for each (parent) job match the current branch of the patch against all branches of the project in which the job is defined. If no such branch exist in a project, then no job variant matches and this job will be ignored [1]. For example, if a patch is submitted for our stable/1.0.0 branch, then Zuul CI will try to match 'stable/1.0.0' against all branches in the projects where job ansible-collections-openstack-functional-devstack and its parent job openstacksdk-functional-devstack are defined. The first is defined in openstack/ansible-collections-openstack/.zuul.yaml, so a match for stable/1.0.0 will be found. But openstacksdk-functional-\ devstack is defined in openstack/openstacksdk/.zuul.yaml which has no branch stable/1.0.0 defined. So Zuul will not schedule job ansible-\ collections-openstack-functional-devstack at all. The solution is twofold. First, the base jobs such as ansible-\ collections-openstack-functional-devstack have to be changed to always checkout existing branches in projects which define (parent) jobs. Using job.override-checkout might have unintended sideeffects because it will checkout the specified branch for all required projects which also includes the project which the patch was submitted for. Instead we set job.required-projects.override-checkout for all projects which define parent jobs. For example, in ansible-collections-openstack-\ functional-devstack we set job.required-projects.override-checkout to master for opendev.org/openstack/devstack which defines parent job openstack-functional-devstack. In child jobs which (re)define job.override-checkout, we have to change job.required-projects.override-checkout for all projects which define parent jobs to the value of job.override-checkout. If we fail to update job.required-projects.override-checkout then Zuul will checkout the branch which was defined in the base jobs because job.\ required-projects.override-checkout has higher precedence than job.\ override-checkout. Setting attribute project.<pipeline>.debug to true helps with debugging these job scheduling issues. "If this is set to true, Zuul will include debugging information in reports it makes about items in the pipeline. This should not normally be set, but in situations were it is difficult to determine why Zuul did or did not run a certain job, the additional information this provides may help" [2]. Note, once job scheduling has been completed, Zuul will use a different algorithm to checkout projects which are listed in job.\ required-projects [3][4]. It will fallback to a default branch if no matching branch can be found in projects [5]. Ref.: [1] https://opendev.org/zuul/zuul/src/branch/master/zuul/model.py#L6996 [2] https://zuul-ci.org/docs/zuul/latest/config/project.html#attr-project.%3Cpipeline%3E.debug [3] https://zuul-ci.org/docs/zuul/latest/job-content.html#git-repositories [4] https://opendev.org/zuul/zuul/src/branch/master/zuul/executor/server.py#L1648 [5] https://zuul-ci.org/docs/zuul/latest/config/project.html#attr-project.default-branch Change-Id: I31f9607ab7e2e2ae8534429da7f5e5f235560c56 |
||
---|---|---|
changelogs | ||
ci | ||
contrib | ||
docs | ||
meta | ||
plugins | ||
scripts/inventory | ||
tests | ||
tools | ||
.gitignore | ||
.gitreview | ||
.zuul.yaml | ||
CHANGELOG.rst | ||
CONTRIBUTING.rst | ||
COPYING | ||
README.md | ||
bindep.txt | ||
galaxy.yml | ||
galaxy.yml.in | ||
requirements.txt | ||
setup.cfg | ||
setup.py | ||
test-requirements-2.9.txt | ||
test-requirements-2.11.txt | ||
test-requirements-2.12.txt | ||
test-requirements.txt | ||
tox.ini |
README.md
Ansible Collection: openstack.cloud
This repo hosts the openstack.cloud
Ansible Collection.
The collection includes the Openstack modules and plugins supported by Openstack community to help the management of Openstack infrastructure.
Installation and Usage
Installing dependencies
For using the Openstack Cloud collection firstly you need to install ansible
and openstacksdk
Python modules on your Ansible controller.
For example with pip:
pip install "ansible>=2.9" "openstacksdk>=0.36"
OpenStackSDK has to be available to Ansible and to the Python interpreter on the host, where Ansible executes the module (target host). Please note, that under some circumstances Ansible might invoke a non-standard Python interpreter on the target host. Using Python version 3 is highly recommended for OpenstackSDK and strongly required from OpenstackSDK version 0.39.0.
NOTE
OpenstackSDK is better to be the last stable version. It should NOT be installed on Openstack nodes, but rather on operators host (aka "Ansible controller"). OpenstackSDK from last version supports operations on all Openstack cloud versions. Therefore OpenstackSDK module version doesn't have to match Openstack cloud version usually.
Installing the Collection from Ansible Galaxy
Before using the Openstack Cloud collection, you need to install the collection with the ansible-galaxy
CLI:
ansible-galaxy collection install openstack.cloud
You can also include it in a requirements.yml
file and install it through ansible-galaxy collection install -r requirements.yml
using the format:
collections:
- name: openstack.cloud
Playbooks
To use a module from the Openstack Cloud collection, please reference the full namespace, collection name, and module name that you want to use:
---
- name: Using Openstack Cloud collection
hosts: localhost
tasks:
- openstack.cloud.server:
name: vm
state: present
cloud: openstack
region_name: ams01
image: Ubuntu Server 14.04
flavor_ram: 4096
boot_from_volume: True
volume_size: 75
Or you can add the full namespace and collection name in the collections
element:
---
- name: Using Openstack Cloud collection
hosts: localhost
collections:
- openstack.cloud
tasks:
- server_volume:
state: present
cloud: openstack
server: Mysql-server
volume: mysql-data
device: /dev/vdb
Usage
See the collection docs at Ansible site:
Contributing
For information on contributing, please see CONTRIBUTING
There are many ways in which you can participate in the project, for example:
- Submit bugs and feature requests, and help us verify them
- Submit and review source code changes in Openstack Gerrit
- Add new modules for Openstack Cloud
We work with OpenDev Gerrit, pull requests submitted through GitHub will be ignored.
Testing and Development
If you want to develop new content for this collection or improve what is already here, the easiest way to work on the collection is to clone it into one of the configured COLLECTIONS_PATHS
, and work on it there.
Testing with ansible-test
We use ansible-test
for sanity:
tox -e linters
More Information
TBD
Communication
We have a dedicated Interest Group for Openstack Ansible modules.
You can find other people interested in this in #openstack-ansible-sig
on OFTC IRC.
License
GNU General Public License v3.0 or later
See LICENCE to see the full text.