feat: add role fingerprints to syslog#181
Merged
Merged
Conversation
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>
Reviewer's GuideAdds an sr_fingerprint Ansible module to write role begin/success markers to syslog, wires it into the postgresql system role, and introduces a journalctl-based test plus sanity ignore files for the new module. Sequence diagram for syslog role fingerprinting on PostgreSQL role runsequenceDiagram
actor Administrator
participant AnsibleController
participant PostgresqlRole_set_vars as PostgresqlRole_set_vars.yml
participant PostgresqlRole_main as PostgresqlRole_main.yml
participant SrFingerprintModule as sr_fingerprint
participant Syslog as System_log
Administrator->>AnsibleController: Run postgresql role playbook
AnsibleController->>PostgresqlRole_set_vars: Execute tasks in set_vars.yml
PostgresqlRole_set_vars->>SrFingerprintModule: sr_fingerprint(sr_message="begin system_role:postgresql ...")
SrFingerprintModule->>SrFingerprintModule: _local_iso8601_no_microseconds()
SrFingerprintModule->>Syslog: module.log("begin system_role:postgresql ... <timestamp>")
SrFingerprintModule-->>PostgresqlRole_set_vars: exit_json(changed=False)
AnsibleController->>PostgresqlRole_main: Execute tasks in main.yml
PostgresqlRole_main->>PostgresqlRole_main: Configure PostgreSQL
PostgresqlRole_main->>SrFingerprintModule: sr_fingerprint(sr_message="success system_role:postgresql ...")
SrFingerprintModule->>SrFingerprintModule: _local_iso8601_no_microseconds()
SrFingerprintModule->>Syslog: module.log("success system_role:postgresql ... <timestamp>")
SrFingerprintModule-->>PostgresqlRole_main: exit_json(changed=False)
PostgresqlRole_main-->>AnsibleController: Role completed
AnsibleController-->>Administrator: Report role finished successfully
Class diagram for sr_fingerprint Ansible module structureclassDiagram
class SrFingerprintModule {
+run_module()
+main()
-_local_iso8601_no_microseconds() str
}
class AnsibleModule {
+params dict
+check_mode bool
+log(message)
+exit_json(**kwargs)
}
class datetime {
+datetime.now(tz)
+timezone.utc
}
class time {
+strftime(format, struct_time)
+localtime()
}
SrFingerprintModule ..> AnsibleModule : uses
SrFingerprintModule ..> datetime : uses
SrFingerprintModule ..> time : fallback_uses
SrFingerprintModule : +attribute sr_message
SrFingerprintModule : +behavior log_fingerprint_message()
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Contributor
Author
|
[citest] |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 1 issue, and left some high level feedback:
- The begin/success fingerprint messages are duplicated in set_vars.yml and main.yml; consider factoring the common format (role name, ansible version, distro/version) into a variable or helper to keep them consistent and easier to update.
- The journalctl-based test relies on a shell pipeline and unanchored grep; using
ansible.builtin.command/ansible.builtin.shellwithfailed_whenplus stricter matching (e.g.grep -For clearer patterns) would make the check more robust and easier to debug. - The test currently only checks for /dev/log before using journalctl; you may want to also gate it on
ansible_service_mgr == 'systemd'or verify that journalctl is available to avoid failures on non-systemd or minimal environments.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The begin/success fingerprint messages are duplicated in set_vars.yml and main.yml; consider factoring the common format (role name, ansible version, distro/version) into a variable or helper to keep them consistent and easier to update.
- The journalctl-based test relies on a shell pipeline and unanchored grep; using `ansible.builtin.command`/`ansible.builtin.shell` with `failed_when` plus stricter matching (e.g. `grep -F` or clearer patterns) would make the check more robust and easier to debug.
- The test currently only checks for /dev/log before using journalctl; you may want to also gate it on `ansible_service_mgr == 'systemd'` or verify that journalctl is available to avoid failures on non-systemd or minimal environments.
## Individual Comments
### Comment 1
<location path="library/sr_fingerprint.py" line_range="28" />
<code_context>
+ sr_message: "system_role:ROLENAME"
+"""
+
+RETURN = r""" # """
+
+from ansible.module_utils.basic import AnsibleModule
</code_context>
<issue_to_address>
**issue (bug_risk):** RETURN spec is not valid YAML and may break ansible-doc / sanity checks.
Using `RETURN = r""" # """` produces invalid YAML for Ansible’s docs parser and can cause `ansible-doc` and sanity checks to fail (or require suppression via ignore files). Either provide a minimal valid YAML structure (e.g. an empty mapping) or drop the `RETURN` variable entirely if you don’t need documented return fields, so tooling continues to work without relying on ignores.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| sr_message: "system_role:ROLENAME" | ||
| """ | ||
|
|
||
| RETURN = r""" # """ |
There was a problem hiding this comment.
issue (bug_risk): RETURN spec is not valid YAML and may break ansible-doc / sanity checks.
Using RETURN = r""" # """ produces invalid YAML for Ansible’s docs parser and can cause ansible-doc and sanity checks to fail (or require suppression via ignore files). Either provide a minimal valid YAML structure (e.g. an empty mapping) or drop the RETURN variable entirely if you don’t need documented return fields, so tooling continues to work without relying on ignores.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 syslog fingerprinting for the PostgreSQL system role and verify it via journal inspection.
New Features:
Tests: