Prior to using ansible for managing the contents of /etc/hosts, we had an implicit guarantee that the inode of /etc/hosts never changes when the file is updated.
This is particularly since we've containerized our deployment: every container is configured to bind-mount /etc/hosts directly, so as soon as the inode of /etc/hosts changes on the host, the container gets out of sync and cannot see further changes to the file unless it's restarted.
In Ansible however, actions on files are all designed to expose changes atomically, and they all ultimately use core module atomic_move [1]. The latter implements atomic change by using the equivalent of rename() syscall internally, which makes the inode of a file change.
The changing inode breaks the container assumption and impacts various use cases, for example:
. When replacing a controller node in the control plane, the new controller ip is never seen by running containers. This breaks e.g. galera that cannot connect to the newly added node
. If for any reason an existing FQDN need to change its IP, no running container will pick it up: for example changing the address of a VIP cannot work without restarting all containers.
[1] https://docs.ansible.com/ansible/latest/reference_appendices/module_utils.html#ansible.module_utils.basic.AnsibleModule.atomic_move
Fix proposed to branch: master
Review: https:/