If people set options in `docker_daemon_options` (e.g. `{'ipv6': false}`), the role will create the `/etc/docker/daemon.json` file and populate it with the options.
Later on, if people stop setting *all of these* options, the file used to remain in place (containing the old options) and cause trouble. This is unexpected.
If the Docker installation is managed by this role and the `/etc/docker/daemon.json` file is managed by it, it should also take care to:
- either delete the file when it's no longer necessary
- or populate it with empty options if that is what `docker_daemon_options` contains
Deleting the file instead of putting `{}` in it seems like the cleaner approach.
There's a chance that people would like to manage options in `/etc/docker/daemon.json` by themselves (without Ansible) and this new behavior when `docker_daemon_options` is empty, but this runs against having a managed Docker installation via Ansible.
This patch only deletes the `/etc/docker/daemon.json` file.
We could possibly delete the `/etc/docker` directory too, but it's more tricky to delete it only when it's empty. In some cases, the directory may contain other files and invoking the `file` module with `state: absent` will delete everything recursively, which is undesirable.
This patch ensures that the correct filename is specified based on the distribution. Observed this behaviour on a Debian system, the old file was not removed due to it being hardcoded to ubuntu instead.
As described in https://github.com/ansible/ansible/issues/65687, get_url
only partially supports check_mode: "the changed status will reflect
comparison to an empty source file".
Before this change, executing this code, with the key already being in
place on the target system, would report "OK", while check_mode would
report "changed".
Due to this change, both now either report "OK" or "changed", depending
on the state of the target system.
Why:
Without this modification, we can't use docker with docker_users in same
playbook than the one which install docker.
How:
Check that docker_users are set and not in docker group before include
docker-users.yml. In docker-users.yml we call reset_connection from
ansible.builtin.meta collection after docker-users are added to docker
group.
Manual success tests:
* Try to install docker with only one user in docker-users and not in
docker group => docker-users.yml include
* Try to install docker with only one user in docker-users but the user
is in docker group => docker-users.yml not include
* Try to install docker with 2 users in docker-users, one user in docker
group and the second not => docker-users.yml include
* Try to install docker with 2 users in docker-users, both are in docker
group => docker-users.yml not include
* Try to install docker with 2 users in docker-users, both are not in
docker group => docker-users.yml include
Not all package install handlers implement the `allow_downgrade` option.
For example, using Ansible >= 2.12 on Arch Linux would croak like:
Unsupported parameters for (ansible.legacy.pacman) module: allow_downgrade.
