c83e0e39b1
Previously, all job definitions where shared across each .zuul.yaml in both branches. When a job definition was changed in one branch, Zuul CI could pick the job definition from the other branch, which was not intended. The problem arises when mixing explicit job.branches matchers with implicit branch matching, when defining same jobs on multiple branches. Zuul CI expects that jobs to be defined in one or the other branch, not both at the same time. One should only use job.branches matchers from single-branched projects, e.g. trusted config repos. When defining jobs in branched repositories one selects which job definition to use by the branch associated with the triggering event instead. Each trigger has a branch associated with it, whether it is the branch targeted by the change being proposed, the branch to which a commit merged, a branch attached to a timer trigger etc. This branch name is searched across involved projects in order to determine what job definition should be used. The job.branches directive is rarely applied to a job which will be copied to multiple branches. When you have multiple copies of a job with the job.branches attribute, Zuul CI could pick any of the job definitions which might not be the one you expected. The job.branches attribute is useful in single branch config repositories where a specific job definition has to be applied to a specific branch of the repository. Another definition of the job will exist in another branch of the config repository. This patch removes job definitions which are specific to other branches, except for parent jobs which are shared across branches. Signed-off-by: Jakob Meng <code@jakobmeng.de> Change-Id: Idb8720bd96843b7807dd5cb62b30c1edf3a7a37c
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.
⚠️ WARNING: This collection is currently being ported to the upcoming OpenStack SDK 1.* release. SDK version 1.* introduces numerous API changes which break backward compatibility with previous 0.* releases. Since keeping a single collection release compatible with both SDK series is not sustainable, our collection codebase has been split: Branch stable/1.0.0 and 1.*.* releases of the collection are compatible with previous OpenStack SDK 0.* releases only. The master branch and upcoming 2.*.* releases of this collection will be compatible with SDK 1.* only. Both branches will continue to be maintained for now. Patches from master will be backported to stable/1.0.0 on a best effort basis but expect new features to be introduced in the master branch only. Contributions are welcome for both branches! ⚠️
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.