
Allow to update server attributes such as its description. Changed default value of server attribute 'security_groups' from ['default'] to [] because the latter is the default in python-openstackclient [1] and the former behavior causes issues with existing servers [2]: Previously, when no 'security_groups' parameter was given, the server module would change existing servers to use the default security group, dropping all other security groups assigned to the server. Our (undocumented) guideline when writing modules is to only add or change what has been requested by the user and to stick to defaults from openstacksdk and python-openstackclient whenever possible. Since we have to break backward compatibility with the next release anyway, we take this opportunity to clean up this odd behavior. Now, when no security groups are given, then security groups of an existing server will not be touched. Closes story #2007893 [2]. Note, Nova will create a server in the default security group, if the security_groups parameter is omitted. Dropped 'openstack' field from server module's results. This variable expanded to additional server information which might be useful for Ansible inventories and was filled from openstacksdk's get_openstack_vars() function [3]. Variables in this function can make additional cloud queries to retrieve additional data, so calling this function can be expensive [4]. Users can use *_info modules to retrieve this data on-demand. Dropped 'availabity_zone' attribute from generic OpenStackModule arguments and inserted it into server and volume modules because it is relevant to those two modules only. This is completes what was started years ago [5] and is possible now since we have breaking changes anyway. Switched attribute name 'userdata' with its alias 'user_data' to match openstacksdk's attribute names which are used e.g. in module results. The previous attribute name 'userdata' is now used as an alias and 'user_data' is used as the attribute name to keep backward compatibility. Wait for server to get into 'ACTIVE' state when creating a server and attribute 'wait' has been set to true. Sorted argument specs and documentation of the server module and marked attributes which are not updatable. Changed unstable bash script example in server module documentation. Renamed server's module attribute 'delete_fip' to 'delete_ips' to match openstacksdk and clarify that it includes all floating ip addresses of the server. Renamed server_info's module attribute 'server' to 'name' and added the former as an alias to be consistent with other *_info modules. Added RETURN fields documentation for the module results of both server and server_info modules. Added description and examples of how to use the 'filters' attribute of the server_info module. Closes story #2007873 [6]. Removed 'openstack_' prefix from module results because the prefix is not consistently used across modules, is more to type without any benefit and removal of the prefix allows us to signal to users that their code for handling module results has to be updated. Many modules have different return values with openstacksdk >= 0.99.0 because it consistently uses resource proxies now. Added assertions for module results to catch future changes in the openstacksdk and our Ansible modules. Added integration tests to check the update mechanism of the server module. Fixed indentation in integration tests. Ensure proper creation and deletion of resources such as networks, subnets and servers in integration tests of server_action module. Renamed ci/roles/server/defaults/main.yaml to main.yml, removing the 'a' in the file extension to be consistent with other filenames. Dropped deprecated function openstack_find_nova_addresses() and incorporated its code directly into the server module because it is not used anywhere else. [1]e49ad1795b/openstackclient/compute/v2/server.py (L1070)
[2] https://storyboard.openstack.org/#!/story/2007893 [3]9e9fc98795/openstack/cloud/_compute.py (L1772)
[4]9e9fc98795/openstack/cloud/meta.py (L482)
[5]9bf33e56dd
[6] https://storyboard.openstack.org/#!/story/2007873 Signed-off-by: Jakob Meng <code@jakobmeng.de> Change-Id: I2f955519a7e8c782b1dab8f94f7a019ed384b81d
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.
Breaking backward compatibility ⚠️
Dear contributors and users of the Ansible OpenStack collection! Our codebase has been split into two separate release series:
2.x.x
releases of Ansible OpenStack collection are compatible with OpenStack SDK1.x.x
and its release candidates0.99.x
only (OpenStack Zed and later). Ourmaster
branch tracks our2.x.x
releases.1.x.x
releases of Ansible OpenStack collection are compatible with OpenStack SDK0.x.x
prior to0.99.0
only (OpenStack Yoga and earlier). Ourstable/1.0.0
branch tracks our1.x.x
releases.
Both branches will be developed in parallel for the time being. Patches from master
will be backported to
stable/1.0.0
on a best effort basis but expect new features to be introduced in our master
branch only.
Contributions are welcome for both branches!
Differences between both branches are mainly renamed and sometimes dropped module return values. We try to keep our
module parameters backward compatible by offering aliases but e.g. the semantics of filters
parameters in *_info
modules have changed due to updates in the OpenStack SDK.
Our decision to break backward compatibility was not taken lightly. OpenStack SDK's first major release (1.0.0
and its
release candidates 0.99.x
) has streamlined and improved large parts of its codebase. For example, its Connection
interface now consistently uses the Resource interfaces under the hood. This required breaking changes from older SDK
releases though. The Ansible OpenStack collection is heavily based on OpenStack SDK. With OpenStack SDK becoming
backward incompatible, so does our Ansible OpenStack collection. We simply lack the devpower to maintain a backward
compatible interface in Ansible OpenStack collection across several SDK releases.
Our first 2.0.0
release is currently under development and we still have a long way to go. If you use modules of the
Ansible OpenStack collection and want to join us in porting them to the upcoming OpenStack SDK, please contact us!
Ping Jakob Meng mail@jakobmeng.de (jm1) or Rafael Castillo rcastill@redhat.com (rcastillo) and we will give you a
quick introduction. We are also hanging around on irc.oftc.net/#openstack-ansible-sig
and irc.oftc.net/#oooq
😎
We have extensive documentation on why, what and how we are adopting and reviewing the new modules, how to set up a working DevStack environment for hacking on the collection and, most importantly, a list of modules where we are coordinating our porting efforts.
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.99.0"
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.