Cannot get log_plays callback to work

Get Help
,
1

To preface; I apologize for asking what is probably a very simple question, but no matter what I try, it just doesn’t work.

I want to collect the output of an Ansible run in a Gitlab pipeline, format it, and send an e-mail with the results - preferably without additional software (like ARA). I came across the log_plays callback plugin and thought it to be exactly the thing that I needed for that first step. However, I cannot seem to get it to work, and I don’t know what I’m missing.

I have the community.general collection installed through ansible-galaxy install -r requirements.yml with the following requirements file:

---
collections:
  - name: community.general
    version: "13.5.0"
    source: https://galaxy.ansible.com

I have enabled the callback plugin in ansible.cfg:

[defaults]
callbacks_enabled = community.general.log_plays

[callback_log_plays]
log_folder = /tmp/log/ansible_hosts

I cannot find any examples of people explicitly enabling the callback or running it in a dedicated job or the like, so as far as I’m aware, it should generate the log files. However, when I check my submitted directory, it is empty. I have also checked the directory above it in case it treats the directory as a file to write to and the default /var/log/ansible/hosts directory in case it ignores it, but all of them were empty. My community general collection version is 13.5.0, Ansible version is 2.16.19. I didn’t get any notification that those were incompatible, but perhaps that is the issue.

Does anyone here know what I might be missing, or what I could investigate to help debug this further? Any help or tips are much appreciated!

2

It works for me with 2.21. See callback community.general.log_plays.

3

One thing worth checking first: whether the ansible.cfg you edited is actually the one being read in your GitLab job (ansible-config dump --only-changed in the pipeline shows the effective config). The log_plays plugin normally creates its log folder on startup (makedirs_safe in the plugin source), so which folders exist or get created can hint at which config took effect; just note a missing custom folder can also mean the path resolved differently, for example via ANSIBLE_LOG_FOLDER or an ini typo falling back to the default /var/log/ansible/hosts. ansible-doc -t callback community.general.log_plays is a decent smoke test that the plugin is discoverable, though it does not prove it is enabled at runtime. One more hypothesis: the community.general 13.x series declares requires_ansible >= 2.18 in its published meta/runtime.yml (your installed copy carries the same file) while you are on core 2.16, so that combination is not officially supported. If the callback errors during a run Ansible only prints a warning, so the start of the job log is worth a scan.

Assisted-by: LLM (drafting, source lookup)

4

ansible-config has a dump option (very useful with --only-changed flag) and a verify option, both should help ensure your configuration is what you expect.

5

Hi everyone, thank you all for your input. ansible-config dump did help me figure out the issue; the ansible.cfg file was indeed being ignored, because the working directory for the pipeline was flagged as being world-writable. I didn’t get any warning regarding this until I ran the config dump, which is somewhat annoying. Luckily it is easily resolved by copying ansible.cfg to ~/.ansible.cfg in the pipeline.

PS: I did also switch to an older version of community.general, specifically 11.4.9. I didn’t end up testing version 13.5 with Ansible 2.16.19, but I do suspect that that would have also resulted in an error had my issue not been with ansible.cfg

6

Start by confirming that Ansible is loading the callback, not merely finding the collection. Run ansible-doc -t callback community.general.log_plays, check ansible-config dump --only-changed, and use the -vvv output to verify the active ansible.cfg, callback path, and enabled callback list. Then confirm that the handler name matches the event for your Ansible version. For example, play-start logic must use the corresponding v2_playbook_on_* callback method. Also check that the configuration keys are in the correct section.

If that still reveals nothing, reduce the test to a one-play, one-task playbook and temporarily add a harmless debug message inside the callback method. This shows whether the plugin was never loaded or whether it loaded but the event or configuration never reached the handler. Once the technical fix is clear, Wordfully’s writing tool can help tighten the troubleshooting notes or documentation.