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 role fingerprint logging to syslog for the rhc system role and verify it via system journal tests.

New Features:

• Introduce an sr_fingerprint Ansible module to write timestamped fingerprint messages to the system log.
• Record begin and success fingerprint messages for the rhc system role including Ansible version and platform details.

Tests:

• Extend repository tests to verify that expected begin and success fingerprint entries are present in the system journal when syslog is available.

Chores:

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

[sourcery-ai]

Reviewer's Guide

Adds a new sr_fingerprint Ansible module to emit role start/success markers to syslog, wires it into the rhc system role at begin/success points, and introduces an end-to-end test that validates the fingerprints via journalctl when /dev/log is available, along with sanity-ignore metadata for the new module across Ansible versions.

Sequence diagram for sr_fingerprint role begin/success logging

sequenceDiagram
    actor Admin
    participant AnsibleController
    participant ManagedHost
    participant sr_fingerprint_module
    participant Syslog

    Admin->>AnsibleController: Run rhc_system_role
    AnsibleController->>ManagedHost: Execute tasks/set_vars.yml
    ManagedHost->>sr_fingerprint_module: Record role begin fingerprint
    sr_fingerprint_module->>sr_fingerprint_module: _local_iso8601_no_microseconds
    alt check_mode_enabled
        sr_fingerprint_module-->>ManagedHost: exit_json(changed=false, message)
    else normal_mode
        sr_fingerprint_module->>Syslog: module.log("begin system_role:rhc ... <timestamp>")
        sr_fingerprint_module-->>ManagedHost: exit_json(changed=false)
    end

    AnsibleController->>ManagedHost: Execute tasks/main.yml
    ManagedHost->>sr_fingerprint_module: Record role success fingerprint
    sr_fingerprint_module->>sr_fingerprint_module: _local_iso8601_no_microseconds
    alt check_mode_enabled
        sr_fingerprint_module-->>ManagedHost: exit_json(changed=false, message)
    else normal_mode
        sr_fingerprint_module->>Syslog: module.log("success system_role:rhc ... <timestamp>")
        sr_fingerprint_module-->>ManagedHost: exit_json(changed=false)
    end

Loading

Class diagram for sr_fingerprint Ansible module

classDiagram
    class sr_fingerprint_module {
        +run_module()
        +main()
        -_local_iso8601_no_microseconds()
    }

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

    sr_fingerprint_module ..> AnsibleModule : uses

    class _local_iso8601_no_microseconds_function {
        +_local_iso8601_no_microseconds() str
    }

    sr_fingerprint_module --> _local_iso8601_no_microseconds_function : calls

    class RoleTasks_set_vars_yml {
        +Record_role_begin_fingerprint()
    }

    class RoleTasks_main_yml {
        +Record_role_success_fingerprint()
    }

    RoleTasks_set_vars_yml --> sr_fingerprint_module : invokes
    RoleTasks_main_yml --> sr_fingerprint_module : invokes

Loading

Flow diagram for rhc role execution with fingerprints

flowchart TD
    A[Start rhc_role] --> B[Load set_vars.yml]
    B --> C[Gather required facts]
    C --> D[Record role begin fingerprint via sr_fingerprint]
    D --> E[Determine if system is ostree and set flag]
    E --> F[Other role tasks]
    F --> G[Conditional tasks in main.yml]
    G --> H[Record role success fingerprint via sr_fingerprint]
    H --> I[End rhc_role]

Loading

File-Level Changes

Change	Details	Files
Introduce sr_fingerprint Ansible module that logs fingerprint messages with timestamps to syslog without reporting changes.	Create library/sr_fingerprint.py implementing an AnsibleModule that accepts a required sr_message parameter. Implement helper to generate local ISO 8601 timestamps without microseconds, with fallback for older Python versions. Concatenate the caller-provided sr_message with the generated timestamp and log it via module.log, honoring check_mode and always returning changed=False.	library/sr_fingerprint.py
Emit role begin and success fingerprint messages from the rhc role using the new module.	Call sr_fingerprint early in tasks/set_vars.yml to record a 'begin system_role:rhc' fingerprint including ansible version and distribution info. Call sr_fingerprint at the end of tasks/main.yml to record a 'success system_role:rhc' fingerprint with the same contextual data. Ensure fingerprints do not influence task changed state by relying on the module’s changed=False behavior.	tasks/set_vars.yml tasks/main.yml
Add an integration-style test that validates fingerprints are written to the system journal when syslog is available, and adjust sanity config for the new module across multiple Ansible versions.	In tests/tests_repositories.yml, detect presence of /dev/log and, when present, capture a start time fact and later search the journal from that point onward. Use journalctl piped through grep to assert presence of both begin and success fingerprint messages for system_role:rhc, filtering out Ansible 'Invoked with' noise and treating missing fingerprints as test failures without marking the task as changed. Introduce .sanity-ansible-ignore-* files for various Ansible minor versions to silence or adapt sanity checks for the custom sr_fingerprint module.	tests/tests_repositories.yml .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.

[sourcery-ai]

Hey - I've left some high level feedback:

• The sr_message strings for the begin/success fingerprints are duplicated in set_vars.yml and main.yml; consider factoring the common parts (role name, Ansible version, distro/version) into a shared variable to avoid divergence over time.
• The journal-check shell task in tests_repositories.yml is fairly brittle (multiple journalctl invocations, plain grep, filtering out Invoked with lines); consider tightening it with a single journalctl call and a more specific regex/anchored pattern so it is less sensitive to log format or unrelated messages.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The `sr_message` strings for the begin/success fingerprints are duplicated in `set_vars.yml` and `main.yml`; consider factoring the common parts (role name, Ansible version, distro/version) into a shared variable to avoid divergence over time.
- The journal-check shell task in `tests_repositories.yml` is fairly brittle (multiple `journalctl` invocations, plain `grep`, filtering out `Invoked with` lines); consider tightening it with a single `journalctl` call and a more specific regex/anchored pattern so it is less sensitive to log format or unrelated messages.

---

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]