Part 1: The Back Story
A lot has changed in the Ansible world recently. The latest being the introduction of Execution Environments.
In this series of posts, I will cover what they are, how to use them and what Pure Storage has made available, but before we dig deep, let’s look in this first post at the major changes in Ansible recently and see how they were all leading to Execution Environments (EE) development.
The Legacy – Ansible 2.x
Before September 2020 installing Ansible, whether through pip or apt/yum, let’s say versions 2.8 or 2.9, was a simple operation. You got everything from this single gigantic package, including the upstream modules from the Ansible community and third-party providers, such as Pure Storage. If you wanted to use the upstream modules, you just called them as with any other module in your playbook.
However, all these modules were causing the codebase to bloat and become unmanageable, particularly the number of GitHub PRs. For some insight, check out this blog post.
Vendors were stuck to the Ansible release cadence to be able to provide new features or bug fixes, which could cause frustration to users who needed issues resolved.
To try and alleviate this Red Hat decided to modularize Ansible and split all vendor and community modules into Collections. These started to appear in Ansible 2.9 and could be installed in parallel to the existing upstream modules in the Ansible distribution, although you had to specify that you wanted to use the collection provided version of a module over the upstream version. I discussed this change in another blog post.
Starting Modularity – Ansible 2.10
September 2020 saw the release of Ansible 2.10 which marked a major change in the architecture of Ansible.
With this release of Ansible, all upstream modules from vendors and the community were removed from the codebase and therefore if you wanted to use these modules, you needed to install the appropriate collection from Ansible Galaxy. At this point, Ansible started to refer to this pared-down package as ansible-base. If you didn’t use any vendor or community modules, then you could install just this. It did include the core modules and plugins that the Ansible team would support directly, such as template, copy, lineinfile, etc.
It is also worth noting that upgrading the ‘legacy’ versions of Ansible to 2.10 required the ‘legacy’ version to be uninstalled first, as pip couldn’t handle the update very smoothly.
I said that all the community and vendor modules and plugins were removed from the 2.10 release. This is not strictly correct – a limited number of community and vendor modules and plugins were included. Specifically, those that had already migrated to Collections and had been pre-certified by Red Hat. These included the Pure Storage Collections for FlashArray and FlashBlade.
To install additional collections required direct installation from source repositories, from https://galaxy.ansible.com/ using ansible-galaxy collection install <namespace.collection> or with a requirements.yml file.
Finally, to add to the changes, Ansible 2.10+ did not ship as an RPM package and was only available from PyPI as a pip package. This blog explains some of the rationales behind that.
Compatibility Issues
With some of the changes to Ansible 2.10, if you wanted to ensure that all your playbooks developed for Ansible 2.9 and earlier were compatible with later versions it was advisable to use the fully qualified module name (FQMN) for each task.
For example, calling the purefa_volume module in Ansible 2.9 would look like this:
---
- name: Pure Storage FlashArray Volume module
tasks:
- name: Create volume
purefa_volume:
name: test
size: 1GBut for Ansible 2.10 and higher, it should look like this:
---
- name: Pure Storage FlashArray Volume module
tasks:
- name: Create volume
purestorage.flasharray.purefa_volume:
name: test
size: 1GYou could also use the collections parameter in the playbook and not use the FQMN to save changing lots of module names in a large playbook or add the collections parameter into the meta/main.yml for any roles you use.
Then Ansible 3.0.0 was released…
February 2021 sees the release of Ansible 3.0.0.
This version was essentially the same as 2.10, in that it included ansible-base 2.10.6+, plus a package of over 90 Ansible Collections, again including the FlashArray and FlashBlade Collections from Pure Storage. It is more accurate to say that Ansible 3.0.0 depended on ansible-base and required a specific version range so that the correct core packages were installed.
Installing the ansible package was still an all-in-one solution, as it automatically installed ansible-base together with modules and plugins from the Collections mentioned above.
Now it’s Ansible 4.0.0…
Fast-forward, not very far, to May 2021 and 4.0.0 appears. To confuse things, ansible-base is renamed to ansible-core and the version for this is bumped to 2.11.
Due to this name change upgrading from Ansible 3.0.0 to Ansible 4.0.0 requires that Ansible be uninstalled and reinstalled.
This is (supposed to be) the end of the architectural transition for Ansible, so now we have covered the recent changes and we are now at a point to discuss the next steps for Ansible, that being Execution Environments and their associated toolsets ansible-runner and ansible-builder.
These are going to be covered in the second blog post in this series.
