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 module to write fingerprint messages to syslog and integrate it into the certificate system role lifecycle.

New Features:

• Introduce the sr_fingerprint Ansible module to log fingerprint messages to the system log.
• Emit begin and success fingerprint messages for the certificate system role including Ansible version and platform information.

Tests:

• Extend the default role test playbook to verify that begin and success fingerprints are written to the system journal for a successful role run.

[sourcery-ai]

Reviewer's Guide

Implements a new Ansible module sr_fingerprint that logs role fingerprint messages to syslog and wires it into the certificate role to emit begin/success markers, with tests verifying the fingerprints appear in the system journal.

Sequence diagram for sr_fingerprint syslog logging during role execution

sequenceDiagram
    actor User
    participant AnsibleController
    participant CertificateRole
    participant SrFingerprintModule
    participant Syslog

    User->>AnsibleController: Run playbook using certificate role
    AnsibleController->>CertificateRole: Execute tasks

    CertificateRole->>SrFingerprintModule: sr_fingerprint sr_message="begin system_role:certificate ..."
    SrFingerprintModule->>SrFingerprintModule: _local_iso8601_no_microseconds()
    alt check_mode
        SrFingerprintModule-->>AnsibleController: exit_json(changed=False, message="Check mode: message not logged ...")
    else normal_mode
        SrFingerprintModule->>Syslog: module.log("begin ... <timestamp>")
        SrFingerprintModule-->>AnsibleController: exit_json(changed=False)
    end

    CertificateRole->>CertificateRole: Perform certificate tasks

    CertificateRole->>SrFingerprintModule: sr_fingerprint sr_message="success system_role:certificate ..."
    SrFingerprintModule->>SrFingerprintModule: _local_iso8601_no_microseconds()
    alt check_mode
        SrFingerprintModule-->>AnsibleController: exit_json(changed=False, message="Check mode: message not logged ...")
    else normal_mode
        SrFingerprintModule->>Syslog: module.log("success ... <timestamp>")
        SrFingerprintModule-->>AnsibleController: exit_json(changed=False)
    end

Loading

Class diagram for the new sr_fingerprint Ansible module

classDiagram
    class SrFingerprintModule {
        +str sr_message
        +run_module()
        +_local_iso8601_no_microseconds() str
        +main()
    }

    class AnsibleModule {
        +dict params
        +log(str message)
        +exit_json(bool changed, str message)
    }

    SrFingerprintModule --> AnsibleModule : uses

    class DateTimeLibrary {
        +now()
        +astimezone()
        +isoformat()
    }

    SrFingerprintModule --> DateTimeLibrary : uses for timestamps

Loading

Flow diagram for certificate role with begin/success fingerprints

flowchart TD
    A["Start certificate role"] --> B["tasks/set_vars.yml: Gather required facts"]
    B --> C["tasks/set_vars.yml: Record role begin fingerprint using sr_fingerprint"]
    C --> D["tasks/main.yml: Execute main certificate tasks"]
    D --> E["tasks/main.yml: Record role success fingerprint using sr_fingerprint"]
    E --> F["End certificate role"]

Loading

File-Level Changes

Change	Details	Files
Introduce sr_fingerprint Ansible module for writing fingerprint messages to syslog with a timestamp.	Add custom module that accepts a required sr_message string parameter. Generate an ISO-8601 local timestamp without microseconds, handling environments without datetime.timezone. Compose the final log line as the sr_message plus the timestamp and send it via module.log. Ensure the module is check-mode aware and always reports changed=False.	library/sr_fingerprint.py
Emit role begin/success fingerprint messages from the certificate role.	At variable setup time, log a begin fingerprint including role name, Ansible version, and distribution/version. At the end of the main task sequence, log a success fingerprint with the same contextual information. Use a consistent sr_message format prefixed with sr_fingerprint and system_role:certificate for easier log parsing.	tasks/set_vars.yml tasks/main.yml
Add an integration-style test that validates role fingerprints are written to the system journal.	Record the start time before running the role using ansible_facts date_time. After role execution, query journalctl since the recorded time and search for begin and success fingerprints for the certificate role. Filter out Ansible "Invoked with" noise from journalctl output and fail the task with explicit error messages if expected fingerprints are missing. Mark the shell check task as not changing state.	tests/tests_default.yml
Maintain Ansible sanity ignore lists for multiple core versions (no functional changes).	Touch or update multiple .sanity-ansible-ignore-* files to keep sanity checks passing across Ansible versions.	.sanity-ansible-ignore-2.9.txt .sanity-ansible-ignore-2.10.txt .sanity-ansible-ignore-2.11.txt .sanity-ansible-ignore-2.12.txt .sanity-ansible-ignore-2.13.txt .sanity-ansible-ignore-2.14.txt .sanity-ansible-ignore-2.15.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.

[sourcery-ai]

Hey - I've left some high level feedback:

• The sr_fingerprint module always logs in local time with a derived timezone offset; if you need consistent cross-host correlation it may be worth including the host name explicitly in sr_message or logging a UTC timestamp alongside the local one.
• The journal check in tests_default.yml currently uses a fairly brittle shell pipeline; consider calling journalctl via the command module, registering its output, and asserting on the presence of the begin/success fingerprints in YAML (to avoid issues with multiple matches, quoting, and pipefail handling).

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The `sr_fingerprint` module always logs in local time with a derived timezone offset; if you need consistent cross-host correlation it may be worth including the host name explicitly in `sr_message` or logging a UTC timestamp alongside the local one.
- The journal check in `tests_default.yml` currently uses a fairly brittle shell pipeline; consider calling `journalctl` via the `command` module, registering its output, and asserting on the presence of the begin/success fingerprints in YAML (to avoid issues with multiple matches, quoting, and pipefail handling).

---

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]

[richm]

[citest]

[richm]

[citest]