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 role-internal fingerprinting mechanism that logs begin/success markers to syslog when the systemd role runs and verify them via tests.

New Features:

• Introduce an sr_fingerprint Ansible module to write timestamped fingerprint messages to syslog.
• Log begin and success fingerprints for the systemd role executions, including Ansible and platform details.

Tests:

• Add an integration test that verifies the role writes the expected begin and success fingerprint messages to the system journal when syslog is available.

Chores:

• Add Ansible sanity ignore configuration files for multiple Ansible versions.

[sourcery-ai]

Reviewer's Guide

Adds a new sr_fingerprint Ansible module that logs role start/success fingerprints to syslog and wires it into the systemd role along with a journalctl-based test, plus sanity-ignore entries for the new module across multiple Ansible versions.

Sequence diagram for role fingerprints being logged to syslog

sequenceDiagram
    actor User
    participant AnsibleController
    participant SystemdRole
    participant Sr_fingerprint_module
    participant Syslog

    User->>AnsibleController: Run playbook including systemd_role
    AnsibleController->>SystemdRole: Execute tasks/main.yml

    Note over SystemdRole: Begin fingerprint task
    SystemdRole->>Sr_fingerprint_module: Call sr_fingerprint sr_message="begin system_role:systemd ..."
    Sr_fingerprint_module->>Sr_fingerprint_module: _local_iso8601_no_microseconds()
    alt check_mode true
        Sr_fingerprint_module-->>AnsibleController: exit_json(changed=false, message="Check mode: message not logged ...")
    else check_mode false
        Sr_fingerprint_module->>Syslog: module.log("begin ... <timestamp>")
        Syslog-->>Sr_fingerprint_module: Log recorded
        Sr_fingerprint_module-->>AnsibleController: exit_json(changed=false)
    end

    AnsibleController->>SystemdRole: Continue remaining role tasks

    Note over SystemdRole: Success fingerprint task (on successful completion)
    SystemdRole->>Sr_fingerprint_module: Call sr_fingerprint sr_message="success system_role:systemd ..."
    Sr_fingerprint_module->>Sr_fingerprint_module: _local_iso8601_no_microseconds()
    alt check_mode true
        Sr_fingerprint_module-->>AnsibleController: exit_json(changed=false, message="Check mode: message not logged ...")
    else check_mode false
        Sr_fingerprint_module->>Syslog: module.log("success ... <timestamp>")
        Syslog-->>Sr_fingerprint_module: Log recorded
        Sr_fingerprint_module-->>AnsibleController: exit_json(changed=false)
    end

    AnsibleController-->>User: Playbook run complete

Loading

Class diagram for the new sr_fingerprint Ansible module

classDiagram
    class Sr_fingerprint_module {
        +run_module()
        +main()
        +_local_iso8601_no_microseconds()
    }

    class AnsibleModule {
        +params
        +check_mode
        +log(message)
        +exit_json(changed, message)
    }

    Sr_fingerprint_module ..> AnsibleModule : uses

    class Sr_message_param {
        +sr_message : str
    }

    Sr_fingerprint_module ..> Sr_message_param : reads

    class Datetime_helpers {
        +datetime_now()
        +time_localtime()
        +strftime()
        +astimezone()
    }

    Sr_fingerprint_module ..> Datetime_helpers : constructs_timestamp

Loading

File-Level Changes

Change	Details	Files
Introduce sr_fingerprint Ansible module to log fingerprint messages to syslog without marking the play as changed.	Create custom module sr_fingerprint with sr_message parameter and documentation/EXAMPLES metadata. Implement timestamp generation helper producing local ISO8601 timestamps without microseconds and robust fallback for older Python. Use AnsibleModule with supports_check_mode, logging via module.log, and always exit with changed=False so logging is idempotent from Ansible’s perspective.	library/sr_fingerprint.py
Emit begin/success fingerprints from the systemd role using the new sr_fingerprint module.	Add a task at role start that records a begin fingerprint including role identifier, ansible_version, and distro/distversion facts. Add a task at role end that records a success fingerprint with the same metadata. Keep required facts logic intact while reformatting the __required_facts list.	tasks/main.yml
Add an integration test that validates fingerprints are written to the system journal when available.	Stat /dev/log and conditionally enable fingerprint assertions only when system logging is present. Capture a start timestamp fact before role execution to bound the journalctl search window. After role run, use journalctl + grep to assert presence of begin and success sr_fingerprint messages, filtering out Ansible’s "Invoked with" noise and failing the task if fingerprints are missing.	tests/tests_default.yml
Update Ansible sanity configuration to ignore the new module for multiple Ansible versions.	Add empty .sanity-ansible-ignore-* marker files for various Ansible versions (2.14–2.22) to satisfy or bypass 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 found 1 issue, and left some high level feedback:

• The fingerprint message format is duplicated in the begin/success tasks in tasks/main.yml; consider extracting the common prefix/suffix (role name, ansible_version, distro info) into a variable to avoid drift if the format ever changes.
• The journalctl-based test hardcodes the grep patterns for sr_fingerprint.*begin system_role:systemd and success system_role:systemd; if the role name or format changes, this will silently become stale, so you might want to build these patterns from a shared variable to keep them aligned with the sr_fingerprint calls.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The fingerprint message format is duplicated in the begin/success tasks in `tasks/main.yml`; consider extracting the common prefix/suffix (role name, ansible_version, distro info) into a variable to avoid drift if the format ever changes.
- The journalctl-based test hardcodes the grep patterns for `sr_fingerprint.*begin system_role:systemd` and `success system_role:systemd`; if the role name or format changes, this will silently become stale, so you might want to build these patterns from a shared variable to keep them aligned with the `sr_fingerprint` calls.

## Individual Comments

### Comment 1
<location path="tasks/main.yml" line_range="10-12" />
<code_context>
     length > 0
   vars:
     __required_facts:
-      - distribution
-      - distribution_major_version
-      - os_family
+    - distribution
+    - distribution_major_version
</code_context>
<issue_to_address>
**issue (bug_risk):** List indentation under `__required_facts` likely breaks YAML structure.

The `- distribution` items are now siblings of `__required_facts` instead of values under it, which alters the resulting data (and may even invalidate the YAML). Please re-indent the list so it remains nested under `__required_facts`.
</issue_to_address>

---

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.}

[richm]

[citest]