What would you like to see in the new Ansible report

Development
1

Hello,

me and @ofedoren are redesigning reports from scratch, the gist of our work is throwing away most of the code we have and storing and presenting reports in a new way. We aim to support Puppet, Ansible and OpenSCAP from the day one and good options for plugin authors to add new formats.

We won’t be changing much in the Puppet format, the report data and presentation will remain the same. However both Ansible and OpenSCAP were both designed in a way that reports do “fit” into Puppet ConfigReport implementation. This rewrite is a chance to design better reports for both, we are starting with Ansible.

I did create few test Ansible playbooks and configured Ansible with its built-in JSON callback to see how reports look like:

Now, from what I’ve learned, there are not many common information we can show for each Ansible task. Here is what I was able to find, fill me in what you would like to see in an Ansible report for each host:

  • Hostname
  • Time of the report
  • Statistics (number of tasks applied, failed, skipped…)
  • List of:
    • Task action (e.g. “shell”)
    • Task name
    • Status: changed, failed, skipped

What is a bit surprising is that there is no telemetry (timing) information per individual tasks for each hosts, some tasks do have this (e.g. shell) but most others don’t. Callback is only informed how much time it took to complete across all hosts, if I understand this correctly. This could be presented on a report but with some warning perhaps about what the duration do actually represent.

I am wondering, if this is enough. It looks like Ansible have been designed in a way that tasks do not have necessary common output. This is a bit different from puppet where reports are more of “standard output” captures with some extra information about manifests which created these lines. Maybe to implement some output capturing for specific tasks like shell?

There is also a common key “invocation” which contains a lot of input data for each task, I am wondering how useful that would be. Some tasks, however, have ton of these (mostly set to null), maybe filtering out null values could make it more readable.

Finally, one major difference between Puppet and Ansible report seems to be diff. In Ansible, diff is only shown when explicitly executed with --diff argument. Since Foreman does not support diff for Ansible reports today, we will not implement it, but I would love to hear opinions about that. I think that diff show in reports is a very useful feature for Puppet users.

3

Hello,

just recently I created an example ansible role representing some common tasks. Feel free to use that for creating testing GitHub - ares/foreman_ansible_test report. I also created an example of what I’d like to see in a report for such role run. This is roughly what I’d like to see.

level task additional data
info Display all parameters known for the Foreman host No additional data
info Apply role No additional data
info Install the openssh package Nothing to do
info Start and enable the sshd Service “sshd” started (enabled: yes)
info Install the base packages Installed: perl-IO-Socket-IP-0.39-5.el8.noarch
Installed: perl-Digest-1.17-395.el8.noarch
Installed: perl-IO-Socket-SSL-2.066-4.module_el8.3.0+410+ff426aa3.noarch
+ Show More
notice Create the message of the day Rendered template “motd.j2” to “/etc/motd”
notice Update the message of the day Rendered template “motd.j2” to “/etc/motd”
info Create foreman-admins group User group “foreman-admins” present, gid: 1001
info Create user ares User “ares” present, uid: 1000
notice Create a /work directory if it does not exist No additional data
notice Change /work ownership, group and permissions No additional data
info Set the group in /work every now and then Cron job: 0 * * * * chgrp -R foreman-admins /work/* (disabled: no)
info Symlink work from home directory No additional data
notice Copy local /etc/bashrc to remote home dire skeleton Copy “bashrc” to “/etc/skel/bashrc”
notice foreman_ansible_test This system ansible-test.example.com is managed by Satellite
notice foreman_ansible_test "boot.log
dnf.log
dnf.rpm.log
hawkey.log
d41d8cd98f00b204e9800998ecf8427e boot.log
46749f1c85e7f792b01146e23af336fd dnf.log
+ Show more
notice foreman_ansible_test No additional data

All of this data should be available in the callback. We may want to add more “additional data” parsers for commonly used modules later, but I think this covers the basic ones.

It may also be interesting to see, if something was skipped, if something was ran in check mode.

In general one thing I find confusing about the reports (regardless of the source) is, that we combine log level with the status of the task/puppet resource/openscap rule. We typically use debug log level if the task was skipped (already in the desired state), notice when it was changed (e.g. package installed) error when it failed (e.g. package unavailable). As a new user, I wouldn’t necessarily understand this and would benefit from seeing “changed”, “nothing to do”, “failed” kind of indicators.

1 Like
4

Thanks that is useful. One thing to realize tho is that we can drop completely how reports are shown today, no need to “map” things to three columns. Therefore I think we should probably show the following columns:

  • Task name
  • Status (Ok, Skipped, Failed…)
  • Additional data

There is no concept of “logs” in ansible callbacks thus no log levels as well. All we can work with are task names, status and additional data which is very different per individual task.

5

Ok since there is undergoing effort to improve Ansible (Foreman legacy) report right now, I have decided to take the default JSON callback and turn it into Foreman Host Report callback. I will perform all the transformation on the proxy and for now I will not do any changes to the JSON callback:

So a generated JSON callback for your example repository looks like this:

In the future, I will add some filtering - dropping irrelevant keys from the report. But the structure will remain the same as I want the report coming out of Ansible to be as close as what Ansible does.

6

FWIW I’d be interested in Foreman supporting Ansible diff mode in reporting. The way I see it, configuration management would benefit from a report alerting on whether a host’s configuration files’ contents, permissions, and owners differ from what Ansible expects. Having this info would be invaluable for enforcing consistent configuration state on hosts imo.

3 Likes