Ansible fails when running in `check` mode

[lucagubler]

So if I run Ansible without --check it will configure the Icinga2 host. And when I then run it with --check it works perfectly fine. But if there are pending changes and I run it with --check, it will fail.

Here are the steps to reproduce:

1. Run it without --check → Host is configured
2. Run it with --check → no changes → it works
3. Add new Icinga2 object
4. Run it with --check → Ansible fails

I think the reason is that the icinga2_fragments are not actually written to /var/tmp/icinga. So Ansible wants to write something to write a new fragment, but it doesn't do it because I run it in check mode. Later it wants to assemble the config. But then it fails and I think the reason is that the fragment it tries to access doesn't exist.

I think we could simply write fragments to /var/tmp/icinga, even if we run Ansible in check mode.

How are you handling this? Are you simply running it without check?

[Donien]

Hi @lucagubler

Indeed, this is a problem many or even most Ansible roles face.

Check mode works perfectly fine with any single module (that supports it) and gives use a nice preview.
Roles, however, tend to be more complex. It quickly becomes extremely difficult to build a role in such a way that check mode works "globally".

Easiest example for the icinga2 role:

• Install Icinga 2
• Run icinga2 daemon -C

In check mode, Icinga 2 is never installed. Thus the icinga2 command is not available.

We could of course instruct the given task to not execute, when check mode is used (when: not ansible_check_mode).

A task that does not execute because of this would also cascade down to other tasks which in turn rely on the first task.
We'd need to put when conditions on these tasks as well. And that's just one problem.
Next we'd have to avoid setting file permissions, since the icinga user on the system is not yet present, meaning all operations including file permissions would need a when: ....

In more complex roles, catching every single case is just not feasible.

I think that is nothing that can really be fixed.

[lucagubler]

I get your point. If you run the Icinga2 role in --check mode on a fresh VM, it will fail. But since it's a fresh VM, it's generally safe to run Ansible.
However, right now Icinga2 is in production. We can't run Ansible in --check mode because it will fail. And we can't really see what's changing. Usually everything goes well. But there's no way to let it run in check mode, verify the output is ok and then configure it. We can only run it and hope it doesn't completely erase the config.

In #389 you mention that we could get rid of /var/tmp/icinga. I think it would bring us closer to getting this collection idempotent.