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 and verify its presence via tests.

New Features:

• Introduce an sr_fingerprint Ansible module to write timestamped fingerprint messages to syslog without changing system state.
• Log role begin and success fingerprints for the kernel_settings system role, including Ansible and platform information.

Tests:

• Extend the default role test to verify that the system journal contains the expected begin and success fingerprint messages when syslog is available.

[sourcery-ai]

Reviewer's Guide

Adds a new sr_fingerprint Ansible module to write timestamped role begin/success markers to syslog and wires it into the kernel_settings role, along with a journal-based test and corresponding sanity ignore updates.

Sequence diagram for logging role begin/success fingerprints to syslog

sequenceDiagram
    actor Operator
    participant AnsibleController
    participant kernel_settings_role
    participant sr_fingerprint_module
    participant Syslog

    Operator->>AnsibleController: Run play using kernel_settings role
    AnsibleController->>kernel_settings_role: Execute tasks/set_vars.yml
    kernel_settings_role->>sr_fingerprint_module: sr_fingerprint(sr_message="begin system_role:kernel_settings ...")
    activate sr_fingerprint_module
    sr_fingerprint_module->>sr_fingerprint_module: _local_iso8601_no_microseconds()
    sr_fingerprint_module->>Syslog: module.log("begin ... <timestamp>")
    sr_fingerprint_module-->>kernel_settings_role: exit_json(changed=False)
    deactivate sr_fingerprint_module

    kernel_settings_role->>kernel_settings_role: Apply kernel settings tasks

    kernel_settings_role->>sr_fingerprint_module: sr_fingerprint(sr_message="success system_role:kernel_settings ...")
    activate sr_fingerprint_module
    sr_fingerprint_module->>sr_fingerprint_module: _local_iso8601_no_microseconds()
    sr_fingerprint_module->>Syslog: module.log("success ... <timestamp>")
    sr_fingerprint_module-->>kernel_settings_role: exit_json(changed=False)
    deactivate sr_fingerprint_module

    kernel_settings_role-->>AnsibleController: Role completed
    AnsibleController-->>Operator: Report successful role run

Loading

Flow diagram for kernel_settings role with begin/success fingerprints

flowchart TD
    A[Start kernel_settings role] --> B[Run tasks/set_vars.yml]
    B --> C[Call sr_fingerprint module with sr_message begin system_role:kernel_settings ...]
    C --> D[Syslog contains begin fingerprint with timestamp]
    D --> E[Execute kernel settings configuration tasks]
    E --> F[Run tasks/main.yml tail tasks]
    F --> G[Call sr_fingerprint module with sr_message success system_role:kernel_settings ...]
    G --> H[Syslog contains success fingerprint with timestamp]
    H --> I[Role completes without reporting changed status from fingerprints]

Loading

File-Level Changes

Change	Details	Files
Introduce sr_fingerprint Ansible module for writing fingerprint messages to syslog without reporting changes.	Create custom module that accepts a required sr_message string parameter. Generate an ISO-8601 local timestamp without microseconds, compatible with older Python versions. Compose final log message as the provided fingerprint string plus timestamp and emit via module.log. Honor Ansible check mode by skipping logging while returning an explanatory message. Always return changed=False so fingerprint logging does not affect idempotency.	library/sr_fingerprint.py
Emit role begin and success fingerprints from the kernel_settings role using the new module.	Add a begin fingerprint task early in variable setup to log role start with role name, Ansible version, and distribution info. Add a success fingerprint task at the end of main tasks to log successful completion with same contextual data. Ensure both fingerprint tasks are simple sr_fingerprint invocations so they remain no-op with respect to changed state.	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.	Check for existence of /dev/log and skip fingerprint assertions when unavailable. Capture a journal start timestamp via ansible_facts before running the role to bound the log search. After running the role, use journalctl and grep to assert presence of begin and success fingerprints while excluding Ansible "Invoked with" noise. Mark the journal-check shell task as not changing state for test idempotency.	tests/tests_default.yml
Update Ansible sanity ignore lists to accommodate the new custom module for multiple Ansible versions.	Touch/update per-version .sanity-ansible-ignore files so the new library module does not fail sanity checks across supported 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 fingerprint message format (role name, ansible version, distro/version) is duplicated between the begin and success tasks; consider centralizing this into a variable or template so that future changes only need to be made in one place.
• In the sr_fingerprint module, it may be helpful to include the final log message in the exit_json payload (e.g. under a logged_message key) to make it easier to debug or verify behavior without having to inspect syslog.
• The journalctl-based fingerprint test assumes journalctl is present and working; if this role is expected to run on systems without journald, consider detecting journalctl availability and conditionally skipping the fingerprint verification rather than failing the test.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The fingerprint message format (role name, ansible version, distro/version) is duplicated between the begin and success tasks; consider centralizing this into a variable or template so that future changes only need to be made in one place.
- In the sr_fingerprint module, it may be helpful to include the final log message in the exit_json payload (e.g. under a `logged_message` key) to make it easier to debug or verify behavior without having to inspect syslog.
- The journalctl-based fingerprint test assumes journalctl is present and working; if this role is expected to run on systems without journald, consider detecting journalctl availability and conditionally skipping the fingerprint verification rather than failing the test.

---

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]