Round Two

Smaller Chunks

Ansible previously integrated files related to specific tasks (include directives) during parsing, similar to the C preprocessor, and the parser often discovered inconsistencies.

The new 2.0 version only parses the files when Ansible processes them, which can lead to problems with loops that are intended to run against all interfaces. Ansible cannot know in advance what tasks are waiting in a yet-to-be-evaluated include file. The developers will be looking to solve this problem, which also affects tags, in a release in the near future.

The delegate_facts flag was recently introduced to supplement the delegate_to command, which makes it possible to import information from another host (e.g., when the administrator on host A needs the IP address of host B for a configuration setting). Without the new flag, this data ends up in the information of the host being processed. If you were to set the delegate_to flag to True, you would instead access hostvars['B'], which would not otherwise receive this data.

Finally, Ansible also looks for parameters in external files, which previously meant CSV files; however, version 2.0 also looks at INI files.

These files typically consist of sections in square brackets and keyword/value pairs. For the INI file in Listing 2, a call to

{{ lookup('ini', 'key section=test file=test.ini') }}

returns the value string. Property files written in Java can also be used in this way. Although they do not include sections, the call simply uses type=properties instead of section=test.

01 [foo]
02 bar=1
03
04 [test]
05 key=value

Incompatibilities

The complete release notes [5] refer to many "API changes." Unfortunately, the developers do not relate in detail what exactly these changes do, other than a section about escaping with the use of backslashes, which removes the need for quadruple backslashes.

At another point, you will find references to APIs for callback, connection, cache, and lookup plugins.

In the brief test for this article, I noticed that a Junos module I frequently use to configure Juniper devices failed when faced with the Junos version number (Figure 2). It worked perfectly with version 1.9.4 on the same device; therefore, you are advised to take all of your playbooks for a test run before migrating.

Figure 2: If you are considering working with Ansible 2.0, you should test run your playbooks.

Conclusions

Ansible 2.0 comes with a host of new modules – in particular designed for use in cloud environments – that could make the admin's life much easier. Beyond this, the anticipated speed gains and the ability to determine when Ansible will process what host from a group in the playbook are meaningful improvements.

Admins who already use Ansible are advised to test their playbooks thoroughly (as well as any new modules they have installed) before upgrading. Because of the sparsely documented API changes, some incompatibilities can be expected.