Breaking changes in minor version of Ansible

And it’s not a bug, it’s a broken promise of stability.

George Shuklin
OpsOps
2 min readSep 15, 2020

--

Version 2.10 changed the way copy/file/template modules work. Old behavior used umask for new files, new behavior uses mode of the module, with default of 0600. If you have umask 0644, and your tasks has no mode, older Ansible versions creates files with rw-r--r-- permission, newer versions do this with rw-------. Moreover, they changes those permissions even for existing files on existing installations.

It is a mildly annoying change, as you need to prepare your playbooks for 2.10 transition. But it’s not a bug issue. The big issue (and the reason for bold statements in this article) is that this change was backported to 2.8.14 and 2.9.12.

It is a huge breaking change, causing endless scream (https://github.com/ansible/ansible/issues/71200, until it was forcefully shut down).

People got broken environments, sudden headache of fixing hundreds of tasks in Ansible (and reviving dead environments).

This is a broken promise of stable interface.

The documentation stated clearly:

This module is guaranteed to have backward compatible interface changes going forward. [stableinterface]

Now it’s a false statement. Playbook are no longer behave the same way between minor versions.

That means:

You can not trust Ansible promise of stable interfaces. You can not trust Ansible semantic version. If your code work with version X.Y.Z, that’s all. Version X.Y.(Z+1) breaks that.

Remember that incident.

My old version assertion for Ansible looked like this:

My new assertion become more strict after this incident:

P.S. We had ported most of our playbooks to 2.10 few weeks ago, and we have precise version pinning for production. This is not a story of our production issues, it’s a story of community trust impairment.

--

--

George Shuklin
OpsOps

I work at Servers.com, most of my stories are about Ansible, Ceph, Python, Openstack and Linux. My hobby is Rust.