This is the second in a loose sequence of articles looking at new features in Ansible 2.0. In the previous article I looked at the Docker connection driver. In this article, I would like to provide an overview of the new-and-much-improved suite of modules for interacting with an OpenStack environment, and provide a few examples of their use. In versions of Ansible prior to 2.0, there was a small collection of OpenStack modules.

Many of the upgrade guides for OpenStack focus on in-place upgrades to your OpenStack environment. Some organizations may opt for a less risky (but more hardware intensive) option of setting up a parallel environment, and then migrating data into the new environment. In this article, we look at how to use Cinder backups with a shared NFS volume to facilitate the migration of Cinder volumes between two different OpenStack environments.

In Quantum in Too Much Detail, I discussed the architecture of a Neutron deployment in detail. Since that article was published, Neutron gained the ability to handle multiple external networks with a single L3 agent. While I wrote about that back in 2014, I covered the configuration side of it in much more detail than I discussed the underlying network architecture. This post addresses the architecture side. The players This document describes the architecture that results from a particular OpenStack configuration, specifically:

So, the Kilo release notes say: nova-manage migrate-flavor-data But nova-manage says: nova-manage db migrate_flavor_data But that says: Missing arguments: max_number And the help says: usage: nova-manage db migrate_flavor_data [-h] [–max-number <number>] Which indicates that –max-number is optional, but whatever, so you try: nova-manage db migrate_flavor_data –max-number 100 And that says: Missing arguments: max_number So just for kicks you try: nova-manage db migrate_flavor_data –max_number 100 And that says: nova-manage: error: unrecognized arguments: –max_number So finally you try:

In an OpenStack environment, cloud-init generally fetches information from the metadata service provided by Nova. It also has support for reading this information from a configuration drive, which under OpenStack means a virtual CD-ROM device attached to your instance containing the same information that would normally be available via the metadata service. It is possible to generate your network configuration from this configuration drive, rather than relying on the DHCP server provided by your OpenStack environment.