feat: new variable postgresql_secure_logging defaulting to true#184
Merged
Conversation
- Replace literal no_log: true with postgresql_secure_logging variable
- Add no_log: "{{ ansible_verbosity < 2 }}" to package_facts
- Add postgresql_secure_logging: true to defaults/main.yml
- Document postgresql_secure_logging variable in README.md
This change allows users to control logging of potentially sensitive
information by setting postgresql_secure_logging: false for debugging,
while maintaining secure defaults.
For package_facts, the role now uses verbosity-based logging to hide
verbose output unless ansible_verbosity >= 2.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Reviewer's guide (collapsed on small PRs)Reviewer's GuideIntroduces a configurable secure-logging toggle and verbosity-based no_log behavior, replacing hard-coded no_log: true on sensitive tasks and reducing default noise from package_facts while documenting the new behavior. Sequence diagram for Ansible logging behavior with postgresql_secure_loggingsequenceDiagram
actor User
participant AnsibleController
participant RoleDefaults
participant TaskPackageFacts
participant TaskSetPostgresPassword
User->>AnsibleController: Run playbook with verbosity
AnsibleController->>RoleDefaults: Load defaults
RoleDefaults-->>AnsibleController: postgresql_secure_logging = true
AnsibleController->>TaskPackageFacts: Execute package_facts
TaskPackageFacts->>TaskPackageFacts: Evaluate no_log as ansible_verbosity < 2
alt ansible_verbosity < 2
TaskPackageFacts-->>AnsibleController: Package facts (no_log enabled)
else ansible_verbosity >= 2
TaskPackageFacts-->>AnsibleController: Package facts (no_log disabled)
end
AnsibleController->>TaskSetPostgresPassword: Execute psql ALTER USER
TaskSetPostgresPassword->>TaskSetPostgresPassword: Evaluate no_log as postgresql_secure_logging
alt postgresql_secure_logging == true
TaskSetPostgresPassword-->>AnsibleController: Password change (no_log enabled)
else postgresql_secure_logging == false
TaskSetPostgresPassword-->>AnsibleController: Password change (no_log disabled)
end
AnsibleController-->>User: Display logs based on no_log settings
Flow diagram for secure logging and verbosity-based no_log decisionsflowchart TD
A[Start Ansible run] --> B[Load role defaults]
B --> C[postgresql_secure_logging default true]
C --> D[Run package_facts task]
D --> E{Is ansible_verbosity < 2}
E -->|Yes| F[Set no_log true for package_facts]
E -->|No| G[Set no_log false for package_facts]
F --> H[Package facts collected without verbose output]
G --> H
H --> I[Run password update task]
I --> J{postgresql_secure_logging value}
J -->|true| K[Set no_log true for password task]
J -->|false| L[Set no_log false for password task]
K --> M[Hide sensitive data in logs]
L --> N[Expose sensitive data for debugging]
M --> O[Ansible output respects no_log]
N --> O
O --> P[End]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![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:
- When using
postgresql_secure_loggingto controlno_log, consider coercing it explicitly to a boolean (e.g.no_log: "{{ postgresql_secure_logging | bool }}") so that string values like"false"from inventories don’t accidentally evaluate as truthy. - For the
package_factstask, it may be safer to castansible_verbosityto an integer in the expression (e.g.no_log: "{{ (ansible_verbosity | int) < 2 }}") to avoid any unexpected comparison issues if the variable is not already an integer.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- When using `postgresql_secure_logging` to control `no_log`, consider coercing it explicitly to a boolean (e.g. `no_log: "{{ postgresql_secure_logging | bool }}"`) so that string values like `"false"` from inventories don’t accidentally evaluate as truthy.
- For the `package_facts` task, it may be safer to cast `ansible_verbosity` to an integer in the expression (e.g. `no_log: "{{ (ansible_verbosity | int) < 2 }}"`) to avoid any unexpected comparison issues if the variable is not already an integer.
## Individual Comments
### Comment 1
<location path="tasks/main.yml" line_range="137" />
<code_context>
psql -c "ALTER USER postgres WITH ENCRYPTED PASSWORD
'{{ postgresql_password }}';"
- no_log: true
+ no_log: "{{ postgresql_secure_logging }}"
changed_when: false
</code_context>
<issue_to_address>
**nitpick:** Avoid quoting the Jinja expression so `no_log` is treated as a native boolean.
Quoting here makes `no_log` a string (`"True"`/`"False"`), which Ansible will usually coerce, but it’s clearer and safer to keep it as a native boolean. Drop the quotes and rely on the template to yield a boolean:
```yaml
no_log: {{ postgresql_secure_logging }}
```
Please apply the same change to the earlier `no_log` that depends on `ansible_verbosity`.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| psql -c "ALTER USER postgres WITH ENCRYPTED PASSWORD | ||
| '{{ postgresql_password }}';" | ||
| no_log: true | ||
| no_log: "{{ postgresql_secure_logging }}" |
There was a problem hiding this comment.
nitpick: Avoid quoting the Jinja expression so no_log is treated as a native boolean.
Quoting here makes no_log a string ("True"/"False"), which Ansible will usually coerce, but it’s clearer and safer to keep it as a native boolean. Drop the quotes and rely on the template to yield a boolean:
no_log: {{ postgresql_secure_logging }}Please apply the same change to the earlier no_log that depends on ansible_verbosity.
richm
approved these changes
May 7, 2026
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
2 participants
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: Introduce the
postgresql_secure_loggingvariable that defaults totrueand using verbosity-based logging for facts modules.Reason: Currently, all sensitive tasks use hard-coded no_log: true, which makes debugging difficult. Users cannot see credential-related output even when troubleshooting authentication or secret management issues. Additionally, package_facts produces verbose output that clutters logs during normal operation.
Result:
🤖 Generated with Claude Code
Summary by Sourcery
Introduce a configurable secure logging toggle and adjust logging behavior for sensitive tasks and facts gathering.
New Features:
Enhancements: