Editorial review for documentation on logging#11
Open
aneta-petrova wants to merge 1 commit intomasterfrom
Open
Editorial review for documentation on logging#11aneta-petrova wants to merge 1 commit intomasterfrom
aneta-petrova wants to merge 1 commit intomasterfrom
Conversation
Review logging: Remove a few extraneous bits Review logging: Take hammer logging reference to upstream Downstream section seemed more helpful than what was upstream. Review logging: Edits to logging procedures To make them all consistent (easier searchability and predictability). Review logging: Add TODOs Review logging: Merge and edit docs for enabling individual loggers Review logging: Edit retrieving & restarting services Review logging: More updates to increasing logging Review logging: Update assembly introduction to match what is actually described Review logging: Review log dirs and log collecting Review logging: Reorder modules, fix module name Review logging: Replace system metadata table with a list Review logging: Remove WIP comments Review logging: A minor fix Review logging: SME feedback for log dirs Includes creating a variable for apache-log-dir Review logging: Update increasing logging for SmartProxy Review logging: Update increasing logging for puppet server and agent Review logging: Remove increasing logging for postgress Because enabling all statements to be logged is not going to produce anything useful, unless a user really knows what they want. Review logging: Update increasing logging for redis Update Redis service name s/foreman-debug/orcharhino-debug/ for orcharhino builds Introduce attribute project-debug (foreman-debug, orcharhino-debug) Peer review feedback for logging procedures Co-authored-by: Maximilian Kolb <mail@maximilian-kolb.de> Apply suggestions from code review Co-authored-by: Maximilian Kolb <mail@maximilian-kolb.de>
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey there - I've reviewed your changes - here's some feedback:
- Please condense the PR description into a concise summary of the high-level edits rather than including the full commit log, which will ease review and cherry‐picking.
- Since you’ve renamed and removed several documentation files, add redirects or update cross-references to prevent broken links in existing guides.
- Consider splitting this large documentation overhaul into smaller, version-targeted PRs so each set of changes can be reviewed and merged more easily.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Please condense the PR description into a concise summary of the high-level edits rather than including the full commit log, which will ease review and cherry‐picking.
- Since you’ve renamed and removed several documentation files, add redirects or update cross-references to prevent broken links in existing guides.
- Consider splitting this large documentation overhaul into smaller, version-targeted PRs so each set of changes can be reviewed and merged more easily.
## Individual Comments
### Comment 1
<location> `guides/common/modules/proc_increasing-the-logging-levels-to-help-with-debugging.adoc:4` </location>
<code_context>
-By default, {Project} comes with `:INFO` level logging enabled.
-You can increase or decrease the log levels on your {Project}.
+You can increase the logging level of {Project} components to troubleshoot {Project}.
+Increasing the logging level to `debug` provides the most detailed information.
+The default logging level is `info`.
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The introductory sentence is clear, but the logical order of sections could be improved by grouping similar logging procedures together for easier reference.
Consider grouping all component-specific logging instructions (Foreman, Hammer, SmartProxy, etc.) in a consistent order, and possibly providing a summary table at the top for quick navigation. This would help users find the relevant section more efficiently.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/modules/*.adoc`
**Instructions:**
Information is presented in the most logical order and location.
</details>
</issue_to_address>
### Comment 2
<location> `guides/common/modules/ref_log-file-directories.adoc:4` </location>
<code_context>
+= Log File Directories
-{ProjectName} provides system information in the form of notifications and log files.
+The following table provides an overview of selected log directories on {ProjectServer}:
-.Log File Directories for Reporting and Troubleshooting
</code_context>
<issue_to_address>
**suggestion (review_instructions):** This section presents a list of log directories and their contents, but does not describe a user story or scenario.
Consider introducing this section with a user scenario, such as troubleshooting an issue and needing to locate the relevant log files.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/modules/*.adoc,guides/common/*.adoc`
**Instructions:**
Documentation describes a user story rather than a product feature.
</details>
</issue_to_address>
### Comment 3
<location> `guides/common/modules/ref_log-file-directories.adoc:4` </location>
<code_context>
+= Log File Directories
-{ProjectName} provides system information in the form of notifications and log files.
+The following table provides an overview of selected log directories on {ProjectServer}:
-.Log File Directories for Reporting and Troubleshooting
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The documentation lists log directories (features) rather than guiding the user through actions or tasks.
It would be more actionable to explain how a user can use these directories to perform troubleshooting or reporting tasks.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/modules/*.adoc,guides/common/*.adoc`
**Instructions:**
Documentation focuses on actions and tasks to be performed rather than features.
</details>
</issue_to_address>
### Comment 4
<location> `guides/common/modules/ref_log-file-directories.adoc:2` </location>
<code_context>
[id="Log_File_Directories_{context}"]
-= Log File Directories Provided by {Project}
+= Log File Directories
-{ProjectName} provides system information in the form of notifications and log files.
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The new heading 'Log File Directories' does not focus on a task to be performed, but rather on a feature.
Headings should focus on what the user can do or learn, e.g., 'Viewing Log File Directories' or 'Accessing Log File Directories for Troubleshooting'.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/modules/*.adoc,guides/common/*.adoc`
**Instructions:**
The heading focuses on the task to be performed rather than a feature.
</details>
</issue_to_address>
### Comment 5
<location> `guides/common/modules/proc_selective-debugging-with-individual-loggers.adoc:2` </location>
<code_context>
+[id="Selective_Debugging_with_Individual_Loggers_{context}"]
+= Selective Debugging with Individual Loggers
+
+You can enable individual loggers for selective debugging.
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The heading 'Selective Debugging with Individual Loggers' is somewhat task-focused, but could be more explicit about the action to be performed.
Consider revising to 'Enabling Selective Debugging with Individual Loggers' or 'How to Debug Selectively Using Individual Loggers' for greater clarity.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/modules/*.adoc,guides/common/*.adoc`
**Instructions:**
The heading focuses on the task to be performed rather than a feature.
</details>
</issue_to_address>
### Comment 6
<location> `guides/common/modules/ref_system-journal-metadata.adoc:8` </location>
<code_context>
-|AUDIT_ACTION|Audit action performed
-
+AUDIT_ACTION::
+Audit action performed
++
Example: Create, update, or delete
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The phrase 'Audit action performed' uses passive voice; consider revising to active voice.
For example, you could use 'Performs audit action' or 'Audits actions' to avoid passive construction.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/modules/*.adoc,guides/common/*.adoc`
**Instructions:**
Avoid passive voice in verbs.
</details>
</issue_to_address>
### Comment 7
<location> `guides/common/modules/ref_system-journal-metadata.adoc:21` </location>
<code_context>
+Audit resource database ID as a number
+
+AUDIT_ATTRIBUTE::
+Audit resource field or an updated database column
+
+AUDIT_FIELD_OLD::
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The phrase 'an updated database column' uses passive voice; consider revising to active voice.
You could rephrase as 'a database column that was updated' or 'updates to a database column'.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/modules/*.adoc,guides/common/*.adoc`
**Instructions:**
Avoid passive voice in verbs.
</details>
</issue_to_address>
### Comment 8
<location> `guides/common/modules/ref_system-journal-metadata.adoc:24` </location>
<code_context>
+Audit resource field or an updated database column
+
+AUDIT_FIELD_OLD::
+Old audit value of an update action
+
+AUDIT_FIELD_NEW::
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The phrase 'Old audit value of an update action' is ambiguous and may imply passive voice; consider clarifying with active voice.
Consider rephrasing to 'Previous audit value before update' or similar for clarity and active construction.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/modules/*.adoc,guides/common/*.adoc`
**Instructions:**
Avoid passive voice in verbs.
</details>
</issue_to_address>
### Comment 9
<location> `guides/common/modules/ref_system-journal-metadata.adoc:27` </location>
<code_context>
+Old audit value of an update action
+
+AUDIT_FIELD_NEW::
+New audit value of an update action
+
+AUDIT_ID::
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The phrase 'New audit value of an update action' is ambiguous and may imply passive voice; consider clarifying with active voice.
Consider rephrasing to 'Updated audit value' or 'Audit value after update' for clarity and active construction.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/modules/*.adoc,guides/common/*.adoc`
**Instructions:**
Avoid passive voice in verbs.
</details>
</issue_to_address>
### Comment 10
<location> `guides/common/modules/ref_system-journal-metadata.adoc:33` </location>
<code_context>
+Record database ID of the audit subject
+
+AUDIT_ATTRIBUTE::
+Attribute name or column on which an action was performed
++
Example: Name or description
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The phrase 'on which an action was performed' uses passive voice; consider revising to active voice.
You could rephrase as 'Attribute name or column affected by the action' or 'Attribute name or column that received the action'.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/modules/*.adoc,guides/common/*.adoc`
**Instructions:**
Avoid passive voice in verbs.
</details>
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Owner
Author
|
@sourcery-ai review |
There was a problem hiding this comment.
Hey there - I've reviewed your changes - here's some feedback:
- Double-check that all cross-references and include paths have been updated to match the renamed modules (e.g. proc_enabling-debug-logging → ref_overview-of-individual-loggers) to prevent broken links.
- Convert or resolve the remaining TODO comments before merging so unfinished sections aren’t published in the final documentation.
- Include a concrete example demonstrating how to set the new apache-log-dir and project-debug attributes in a sample configuration to improve usability.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Double-check that all cross-references and include paths have been updated to match the renamed modules (e.g. proc_enabling-debug-logging → ref_overview-of-individual-loggers) to prevent broken links.
- Convert or resolve the remaining TODO comments before merging so unfinished sections aren’t published in the final documentation.
- Include a concrete example demonstrating how to set the new apache-log-dir and project-debug attributes in a sample configuration to improve usability.
## Individual Comments
### Comment 1
<location> `guides/common/modules/ref_log-file-directories.adoc:17` </location>
<code_context>
+| `/var/log/foreman-proxy/` | Foreman proxy
+| `/var/log/foreman/` | Foreman
+| `/var/log/{apache-log-dir}/` | Apache HTTP server
+| `/var/log/messages/` | Various other log messages
+| `/var/log/puppetlabs/puppet/` | Puppet
+ifdef::satellite,katello,orcharhino[]
</code_context>
<issue_to_address>
**suggestion (review_instructions):** No troubleshooting or error recognition steps are provided for how to use these log directories to investigate problems.
Consider adding a short note or example on how users can use these log directories for troubleshooting, such as which logs to check for specific types of errors or how to search for error messages.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/modules/*.adoc`
**Instructions:**
Troubleshooting and error recognition steps are included where appropriate.
</details>
</issue_to_address>
### Comment 2
<location> `guides/common/modules/ref_log-file-directories.adoc:4` </location>
<code_context>
+= Log File Directories
-{ProjectName} provides system information in the form of notifications and log files.
+The following table provides an overview of selected log directories on {ProjectServer}:
-.Log File Directories for Reporting and Troubleshooting
</code_context>
<issue_to_address>
**suggestion (review_instructions):** This section presents log directories as features, not in the context of a user story or task.
It would be more helpful to frame this section around the user's goal, such as locating logs for troubleshooting, rather than just listing directories.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/modules/*.adoc,guides/common/*.adoc`
**Instructions:**
Documentation describes a user story rather than a product feature.
</details>
</issue_to_address>
### Comment 3
<location> `guides/common/modules/ref_system-journal-metadata.adoc:4` </location>
<code_context>
The following table lists metadata that the `journald` service uses in {Project}.
You can use this metadata to filter your queries.
</code_context>
<issue_to_address>
**suggestion (review_instructions):** This section lists metadata fields as features rather than describing how a user would use them to accomplish a task.
Consider introducing this section with a user story, such as filtering logs for troubleshooting, and describing how each metadata field helps achieve that goal.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/modules/*.adoc,guides/common/*.adoc`
**Instructions:**
Documentation describes a user story rather than a product feature.
</details>
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Owner
Author
|
@sourcery-ai review |
There was a problem hiding this comment.
Hey there - I've reviewed your changes - here's some feedback:
- Ensure that all renamed module files (e.g., proc_selective-debugging-with-individual-loggers.adoc) are updated in the table of contents and navigation includes so links don’t break.
- Verify that the new project-debug attribute is properly documented in each attributes-*.adoc file so users can find and set it consistently.
- Since the PostgreSQL logging section was removed, consider adding a note or link for advanced users who still need to configure detailed Postgres logging externally.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Ensure that all renamed module files (e.g., proc_selective-debugging-with-individual-loggers.adoc) are updated in the table of contents and navigation includes so links don’t break.
- Verify that the new project-debug attribute is properly documented in each attributes-*.adoc file so users can find and set it consistently.
- Since the PostgreSQL logging section was removed, consider adding a note or link for advanced users who still need to configure detailed Postgres logging externally.
## Individual Comments
### Comment 1
<location> `guides/common/modules/ref_log-file-directories.adoc:4` </location>
<code_context>
+= Log File Directories
-{ProjectName} provides system information in the form of notifications and log files.
+The following table provides an overview of selected log directories on {ProjectServer}:
-.Log File Directories for Reporting and Troubleshooting
</code_context>
<issue_to_address>
**suggestion (review_instructions):** This section lists log directories as features, not as part of a user story.
Consider framing the table in the context of a user needing to locate logs for troubleshooting, e.g., 'When investigating issues, you may need to check the following log directories...'
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/modules/*.adoc,guides/common/*.adoc`
**Instructions:**
Documentation describes a user story rather than a product feature.
</details>
</issue_to_address>
### Comment 2
<location> `guides/common/modules/ref_log-file-directories.adoc:4` </location>
<code_context>
+= Log File Directories
-{ProjectName} provides system information in the form of notifications and log files.
+The following table provides an overview of selected log directories on {ProjectServer}:
-.Log File Directories for Reporting and Troubleshooting
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The documentation presents log directories as features, not as actionable steps for the user.
To better follow the instruction, introduce the table with guidance on how and when a user would use these directories for troubleshooting or reporting problems.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/modules/*.adoc,guides/common/*.adoc`
**Instructions:**
Documentation focuses on actions and tasks to be performed rather than features.
</details>
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Owner
Author
|
@sourcery-ai review |
There was a problem hiding this comment.
Hey there - I've reviewed your changes and they look great!
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location> `guides/common/modules/ref_log-file-directories.adoc:4` </location>
<code_context>
+= Log File Directories
-{ProjectName} provides system information in the form of notifications and log files.
+The following table provides an overview of selected log directories on {ProjectServer}:
-.Log File Directories for Reporting and Troubleshooting
</code_context>
<issue_to_address>
**suggestion (review_instructions):** This added line introduces the table but does not frame it as a user story or user-centric task.
Consider rephrasing to focus on the user's goal, e.g., 'To locate logs for troubleshooting, refer to the following directories on your {ProjectServer}.'
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/*.adoc,guides/common/modules/*.adoc`
**Instructions:**
Documentation describes a user story rather than a product feature.
</details>
</issue_to_address>
### Comment 2
<location> `guides/common/modules/ref_log-file-directories.adoc:8` </location>
<code_context>
-
-You can also use the `foreman-tail` command to follow many of the log files related to {Project}.
-You can run `foreman-tail -l` to list the processes and services that it follows.
+| Log file directory | Description of log file content
+ifdef::satellite,katello,orcharhino[]
+| `/var/log/candlepin/` | Subscription management
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The table header is product-centric; it could be more user-centric by focusing on user actions or needs.
For example, 'Directory to check for logs' or 'Where to find logs for troubleshooting' would be more user-centric.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/*.adoc,guides/common/modules/*.adoc`
**Instructions:**
Documentation uses user-centric language rather than product-centric language.
</details>
</issue_to_address>
### Comment 3
<location> `guides/common/modules/proc_retrieving-status-of-services.adoc:4` </location>
<code_context>
[id="Retrieving_the_Status_of_Services_{context}"]
= Retrieving the Status of Services
+{Project} uses a set of back-end services.
+When troubleshooting, you can check the status of {Project} services.
+
</code_context>
<issue_to_address>
**suggestion (review_instructions):** This line is product-centric and does not describe a user story.
Consider starting with the user's goal, e.g., 'When troubleshooting, you can check the status of {Project} services.'
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/*.adoc,guides/common/modules/*.adoc`
**Instructions:**
Documentation describes a user story rather than a product feature.
</details>
</issue_to_address>
### Comment 4
<location> `guides/common/modules/proc_restarting-services.adoc:4` </location>
<code_context>
[id="Retrieving_the_Status_of_Services_{context}"]
= Retrieving the Status of Services
+{Project} uses a set of back-end services.
+When troubleshooting, you can check the status of {Project} services.
+
</code_context>
<issue_to_address>
**suggestion (review_instructions):** This line is product-centric and does not describe a user story.
Consider starting with the user's goal, e.g., 'When troubleshooting, you can restart the services if needed.'
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/*.adoc,guides/common/modules/*.adoc`
**Instructions:**
Documentation describes a user story rather than a product feature.
</details>
</issue_to_address>
### Comment 5
<location> `guides/common/modules/proc_increasing-the-logging-levels-to-help-with-debugging.adoc:4` </location>
<code_context>
-By default, {Project} comes with `:INFO` level logging enabled.
-You can increase or decrease the log levels on your {Project}.
+You can increase the logging level of {Project} components to troubleshoot {Project}.
+Increasing the logging level to `debug` provides the most detailed information.
+The default logging level is `info`.
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The procedure describes how to increase logging levels but does not explicitly mention troubleshooting or error recognition steps for when issues are encountered.
Consider adding explicit troubleshooting steps or guidance on how to recognize and interpret errors in the logs after increasing the logging level. For example, what should the user look for in the debug logs to identify common problems?
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/modules/proc*.adoc`
**Instructions:**
Troubleshooting and error recognition steps are included where appropriate.
</details>
</issue_to_address>
### Comment 6
<location> `guides/common/modules/proc_increasing-the-logging-levels-to-help-with-debugging.adoc:5` </location>
<code_context>
-By default, {Project} comes with `:INFO` level logging enabled.
-You can increase or decrease the log levels on your {Project}.
+You can increase the logging level of {Project} components to troubleshoot {Project}.
+Increasing the logging level to `debug` provides the most detailed information.
+The default logging level is `info`.
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The instructions for increasing logging levels do not include verification steps to confirm that the new logging level is active.
Please add a verification step, such as checking the log file for debug-level entries or running a command to confirm the logging level has changed.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/modules/proc*.adoc`
**Instructions:**
Verification steps are included where appropriate.
</details>
</issue_to_address>
### Comment 7
<location> `guides/common/modules/proc_selective-debugging-with-individual-loggers.adoc:4` </location>
<code_context>
+[id="Selective_Debugging_with_Individual_Loggers_{context}"]
+= Selective Debugging with Individual Loggers
+
+You can enable individual loggers for selective debugging.
+
+.Procedure
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The procedure for enabling individual loggers does not include troubleshooting or error recognition steps for issues that may arise when enabling or using these loggers.
Consider adding troubleshooting advice, such as what to do if enabling a logger does not work, or how to interpret the output of specific loggers for common problems.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/modules/proc*.adoc`
**Instructions:**
Troubleshooting and error recognition steps are included where appropriate.
</details>
</issue_to_address>
### Comment 8
<location> `guides/common/modules/proc_selective-debugging-with-individual-loggers.adoc:8` </location>
<code_context>
-
-.Procedure
-. Enable the individual loggers that you want.
-For example, to enable `sql` and `ldap` loggers, enter the following command:
-+
-[options="nowrap", subs="+quotes,verbatim,attributes"]
</code_context>
<issue_to_address>
**suggestion (review_instructions):** No verification step is provided to confirm that the individual loggers are enabled and producing output.
Please add a verification step, such as checking the relevant log files for output from the enabled loggers.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `guides/common/modules/proc*.adoc`
**Instructions:**
Verification steps are included where appropriate.
</details>
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
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.
Review logging: Remove a few extraneous bits
Review logging: Take hammer logging reference to upstream
Downstream section seemed more helpful than what was upstream.
Review logging: Edits to logging procedures
To make them all consistent (easier searchability and predictability).
Review logging: Add TODOs
Review logging: Merge and edit docs for enabling individual loggers
Review logging: Edit retrieving & restarting services
Review logging: More updates to increasing logging
Review logging: Update assembly introduction to match what is actually described
Review logging: Review log dirs and log collecting
Review logging: Reorder modules, fix module name
Review logging: Replace system metadata table with a list
Review logging: Remove WIP comments
Review logging: A minor fix
Review logging: SME feedback for log dirs
Includes creating a variable for apache-log-dir
Review logging: Update increasing logging for SmartProxy
Review logging: Update increasing logging for puppet server and agent
Review logging: Remove increasing logging for postgress
Because enabling all statements to be logged is not going to produce anything useful, unless a user really knows what they want.
Review logging: Update increasing logging for redis
Update Redis service name
s/foreman-debug/orcharhino-debug/ for orcharhino builds
Introduce attribute project-debug (foreman-debug, orcharhino-debug)
Peer review feedback for logging procedures
Apply suggestions from code review
What changes are you introducing?
Why are you introducing these changes? (Explanation, links to references, issues, etc.)
Anything else to add? (Considerations, potential downsides, alternative solutions you have explored, etc.)
Contributor checklists
Please cherry-pick my commits into:
Summary by Sourcery
Revise and consolidate Foreman logging documentation to improve consistency, structure, and searchability across logging procedures and reference modules
Enhancements:
Documentation: