feat: add role fingerprints to syslog

[richm]

Feature: Add a fingerprint string to the system log to indicate when the role began
successfully, and when the role finished successfully. The fingerprint string indicates
the role name, a timestamp, and the platform.

Reason: Users can see when the role was used and if it was used successfully. This
information from the system log can be collected by log scanners and aggregators
for further analysis.

Result: The role logs fingerprints to the system log.

This also adds a test to check if the fingerprints were written upon a successful
role invocation.

Signed-off-by: Rich Megginson rmeggins@redhat.com

Summary by Sourcery

Add a custom Ansible module and role hooks to emit syslog fingerprints when the tlog system role starts and completes, and verify their presence via tests.

New Features:

• Introduce the sr_fingerprint Ansible module to write timestamped fingerprint messages to syslog.
• Emit begin and success fingerprint messages from the tlog role including role name, Ansible version, and distribution information.

Tests:

• Add an integration test that runs the role and checks the system journal for the expected begin and success fingerprint entries.

Chores:

• Add Ansible sanity-ignore marker files for multiple Ansible versions and wire the sr_fingerprint module into the test role library path.

[sourcery-ai]

Reviewer's Guide

Adds a new sr_fingerprint Ansible module and wires it into the tlog system role to emit begin/success fingerprints to syslog, along with a test that validates the fingerprints via journalctl and related sanity/compatibility wiring.

Sequence diagram for tlog role begin/success fingerprints via sr_fingerprint

sequenceDiagram
    actor Admin
    participant AnsibleController
    participant ManagedHost
    participant Role_tlog
    participant Module_sr_fingerprint
    participant Syslog

    Admin->>AnsibleController: Run playbook using tlog role
    AnsibleController->>ManagedHost: Execute tlog role tasks

    rect rgb(235, 245, 255)
        Role_tlog->>Module_sr_fingerprint: Record role begin fingerprint
        Module_sr_fingerprint->>Module_sr_fingerprint: _local_iso8601_no_microseconds()
        Module_sr_fingerprint->>Syslog: module.log("begin system_role:tlog ... <timestamp>")
        Module_sr_fingerprint-->>Role_tlog: changed=False
    end

    Role_tlog->>ManagedHost: Execute remaining tlog configuration tasks

    rect rgb(235, 245, 255)
        Role_tlog->>Module_sr_fingerprint: Record role success fingerprint
        Module_sr_fingerprint->>Module_sr_fingerprint: _local_iso8601_no_microseconds()
        Module_sr_fingerprint->>Syslog: module.log("success system_role:tlog ... <timestamp>")
        Module_sr_fingerprint-->>Role_tlog: changed=False
    end

    Role_tlog-->>AnsibleController: Role completed
    AnsibleController-->>Admin: Report success, fingerprints available in syslog

Loading

Class diagram for sr_fingerprint Ansible module structure

classDiagram
    class sr_fingerprint {
        +run_module() void
        +main() void
        -_local_iso8601_no_microseconds() str
    }

    class AnsibleModule {
        +params dict
        +check_mode bool
        +log(message str) void
        +exit_json(**kwargs) void
    }

    class datetime {
        <<library>>
    }

    sr_fingerprint ..> AnsibleModule : uses
    sr_fingerprint ..> datetime : uses

    class run_module_flow {
        +sr_message str
        +log_message str
    }

    sr_fingerprint .. run_module_flow : constructs log_message
    run_module_flow : "log_message = sr_message + ' ' + _local_iso8601_no_microseconds()"

Loading

File-Level Changes

Change	Details	Files
Introduce sr_fingerprint Ansible module to log fingerprint messages to syslog without reporting changes.	Create custom Ansible module sr_fingerprint with sr_message parameter Implement local ISO8601 timestamp helper compatible with old Python versions Log sr_message plus timestamp via module.log, supporting check mode and always reporting changed=False	library/sr_fingerprint.py tests/roles/linux-system-roles.tlog/library
Emit role begin and success fingerprints from the tlog role using sr_fingerprint with platform and Ansible version metadata.	Add begin fingerprint call early in set_vars tasks using sr_fingerprint and include ansible_version and distribution info Add success fingerprint call at the end of main tasks using sr_fingerprint and include ansible_version and distribution info	tasks/set_vars.yml tasks/main.yml
Add test coverage to validate fingerprints are written to the system journal when /dev/log is available.	Extend default test play to record a journal start time if /dev/log exists After running the role, scan journalctl output from the start time for begin and success fingerprint messages, ignoring invocation noise, and fail the test if missing Mark the shell-based fingerprint check as not changing state Guard the journal-based test with a when condition on /dev/log existence	tests/tests_default.yml
Update Ansible sanity configuration for the new module across multiple Ansible versions.	Add per-version .sanity-ansible-ignore files to satisfy or adjust sanity checks for the new module	.sanity-ansible-ignore-2.14.txt .sanity-ansible-ignore-2.16.txt .sanity-ansible-ignore-2.17.txt .sanity-ansible-ignore-2.18.txt .sanity-ansible-ignore-2.19.txt .sanity-ansible-ignore-2.20.txt .sanity-ansible-ignore-2.21.txt .sanity-ansible-ignore-2.22.txt

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[richm]

[citest]

[sourcery-ai]

Hey - I've left some high level feedback:

• The test that greps for sr_fingerprint.*begin system_role:tlog relies on the exact formatting of module.log output and assumes the module name appears in the log line; it would be more robust to either include a distinctive prefix in sr_message itself or adjust the grep to match only content you fully control.
• The journal check currently runs journalctl twice with similar filters; consider invoking journalctl once and running both checks over that output to reduce overhead and avoid any chance of messages appearing between the two calls.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The test that greps for `sr_fingerprint.*begin system_role:tlog` relies on the exact formatting of `module.log` output and assumes the module name appears in the log line; it would be more robust to either include a distinctive prefix in `sr_message` itself or adjust the grep to match only content you fully control.
- The journal check currently runs `journalctl` twice with similar filters; consider invoking `journalctl` once and running both checks over that output to reduce overhead and avoid any chance of messages appearing between the two calls.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}