diff --git a/downstream/assemblies/platform/assembly-ag-controller-config.adoc b/downstream/assemblies/platform/assembly-ag-controller-config.adoc index fad08ea63..d1dacb8e9 100644 --- a/downstream/assemblies/platform/assembly-ag-controller-config.adoc +++ b/downstream/assemblies/platform/assembly-ag-controller-config.adoc @@ -2,22 +2,21 @@ = {ControllerNameStart} configuration -You can configure {ControllerName} settings within the *Settings* screen in the following tabs: +You can configure {ControllerName} settings from the *Systems Settings* screen in the following tabs: image::ag-settings-menu-screen.png[Settings] -Each tab contains fields with a *Reset* option, enabling you to revert any value entered back to the default value. -*Reset All* enables you to revert all the values to their factory default values. - -*Save* applies the changes you make, but it does not exit the edit dialog. -To return to the *Settings* page, from the navigation panel select {MenuAEAdminSettings} or use the breadcrumbs at the top of the current view. +Click btn:[Save] to apply the changes you make. include::platform/proc-controller-authentication.adoc[leveloffset=+1] include::platform/proc-controller-configure-jobs.adoc[leveloffset=+1] include::platform/proc-controller-configure-system.adoc[leveloffset=+1] +//Changed at 2.5 include::platform/proc-controller-configure-user-interface.adoc[leveloffset=+1] +//Changes at 2.5 include::platform/proc-controller-configure-usability-analytics.adoc[leveloffset=+2] -include::platform/con-controller-custom-logos.adoc[leveloffset=+2] +//Doesn't appear to be availaable at 2.5 +//include::platform/con-controller-custom-logos.adoc[leveloffset=+2] include::platform/con-controller-additional-settings.adoc[leveloffset=+1] include::platform/proc-controller-obtaining-subscriptions.adoc[leveloffset=+1] include::platform/con-controller-keep-subscription-in-compliance.adoc[leveloffset=+2] diff --git a/downstream/assemblies/platform/assembly-controller-improving-performance.adoc b/downstream/assemblies/platform/assembly-controller-improving-performance.adoc index 8b59771d4..00563ad03 100644 --- a/downstream/assemblies/platform/assembly-controller-improving-performance.adoc +++ b/downstream/assemblies/platform/assembly-controller-improving-performance.adoc @@ -2,16 +2,16 @@ = Performance tuning for {ControllerName} -Tune your {ControllerName} to optimize performance and scalability. When planning your workload, ensure that you identify your performance and scaling needs, adjust for any limitations, and monitor your deployment. +Tune your {ControllerName} to optimize performance and scalability. +When planning your workload, ensure that you identify your performance and scaling needs, adjust for any limitations, and monitor your deployment. {ControllerNameStart} is a distributed system with multiple components that you can tune, including the following: -* Task system in charge of scheduling jobs -* Control Plane in charge of controlling jobs and processing output -* Execution plane where jobs run -* Web server in charge of serving the API -* Websocket system that serve and broadcast websocket connections and data -* Database used by multiple components +* Task system in charge of scheduling jobs. +* Control Plane in charge of controlling jobs and processing output. +* Web server in charge of serving the API. +* Websocket system that serve and broadcast websocket connections and data. +* Database used by multiple components. include::platform/ref-controller-capacity-planning.adoc[leveloffset=+1] include::platform/ref-controller-workload-characteristics.adoc[leveloffset=+2] diff --git a/downstream/assemblies/platform/assembly-controller-isolation-function-variables.adoc b/downstream/assemblies/platform/assembly-controller-isolation-function-variables.adoc index b610c1663..c66318bd1 100644 --- a/downstream/assemblies/platform/assembly-controller-isolation-function-variables.adoc +++ b/downstream/assemblies/platform/assembly-controller-isolation-function-variables.adoc @@ -10,7 +10,7 @@ You might find that you need to customize your playbook runs to expose additiona To fine tune your use of job isolation, there are certain variables that can be set. By default, {ControllerName} uses the system's `/tmp` directory as its staging area. -You can change this in the *Job Execution Path* field on the *Jobs settings* page, or in the REST API at `/api/v2/settings/jobs`, using: +You can change this in the REST API at `/api/v2/settings/jobs`, using: [literal, options="nowrap" subs="+attributes"] ---- diff --git a/downstream/assemblies/platform/assembly-controller-log-files.adoc b/downstream/assemblies/platform/assembly-controller-log-files.adoc index 46c2e2d21..e624c12b9 100644 --- a/downstream/assemblies/platform/assembly-controller-log-files.adoc +++ b/downstream/assemblies/platform/assembly-controller-log-files.adoc @@ -2,7 +2,7 @@ = {ControllerNameStart} logfiles -{ControllerNameStart} logfiles can be accessed from two centralized locations: +You can access {ControllerName} logfiles from two centralized locations: * `/var/log/tower/` * `/var/log/supervisor/` @@ -16,7 +16,7 @@ In the `/var/log/tower/` directory, you can view logfiles captured by: * *management_playbooks.log:* Captures the logs of management playbook runs, and isolated job runs such as copying the metadata. * *rsyslog.err:* Captures rsyslog errors authenticating with external logging services when sending logs to them. * *task_system.log:* Captures the logs of tasks that {ControllerName} is running in the background, such as adding cluster instances and logs related to information gathering or processing for analytics. -* *tower_rbac_migrations.log:* Captures the logs for rbac database migration or upgrade. +* *tower_rbac_migrations.log:* Captures the logs for RBAC database migration or upgrade. * *tower_system_tracking_migrations.log:* Captures the logs of the controller system tracking migration or upgrade. * *wsbroadcast.log:* Captures the logs of websocket connections in the controller nodes. diff --git a/downstream/assemblies/platform/assembly-controller-logging-aggregation.adoc b/downstream/assemblies/platform/assembly-controller-logging-aggregation.adoc index 82fce2956..92022f424 100644 --- a/downstream/assemblies/platform/assembly-controller-logging-aggregation.adoc +++ b/downstream/assemblies/platform/assembly-controller-logging-aggregation.adoc @@ -3,7 +3,7 @@ = Logging and Aggregation Logging provides the capability to send detailed logs to third-party external log aggregation services. -Services connected to this data feed serve as a means of gaining insight into {ControllerName} use or technical trends. +Services connected to this data feed are a means of gaining insight into {ControllerName} use or technical trends. The data can be used to analyze events in the infrastructure, monitor for anomalies, and correlate events in one service with events in another. The types of data that are most useful to {ControllerName} are job fact data, job events or job runs, activity stream data, and log messages. diff --git a/downstream/images/ag-settings-menu-screen.png b/downstream/images/ag-settings-menu-screen.png index 41c6bcc38..39ad9e823 100644 Binary files a/downstream/images/ag-settings-menu-screen.png and b/downstream/images/ag-settings-menu-screen.png differ diff --git a/downstream/images/configure-controller-jobs-isolated-jobs-fields.png b/downstream/images/configure-controller-jobs-isolated-jobs-fields.png index 61720b80f..dd52a5d47 100644 Binary files a/downstream/images/configure-controller-jobs-isolated-jobs-fields.png and b/downstream/images/configure-controller-jobs-isolated-jobs-fields.png differ diff --git a/downstream/images/configure-controller-system-logging-types.png b/downstream/images/configure-controller-system-logging-types.png index aed9993f0..a88812b17 100644 Binary files a/downstream/images/configure-controller-system-logging-types.png and b/downstream/images/configure-controller-system-logging-types.png differ diff --git a/downstream/modules/platform/con-controller-keep-subscription-in-compliance.adoc b/downstream/modules/platform/con-controller-keep-subscription-in-compliance.adoc index 2e53bb851..060d8a8fe 100644 --- a/downstream/modules/platform/con-controller-keep-subscription-in-compliance.adoc +++ b/downstream/modules/platform/con-controller-keep-subscription-in-compliance.adoc @@ -38,9 +38,9 @@ For example, if you have a subscription capacity of 10 hosts: = Viewing the host activity .Procedure -//[ddacosta] I don't see a Host Metrics menu selection off the standalone navigation panel. Should it be Resources > Hosts? If so, add replace with {MenuInfrastructureHosts} +//[ddacosta] I don't see a Host Metrics menu selection off the standalone navigation panel. Should it be Infrastructure > Hosts? If so, add replace with {MenuInfrastructureHosts} //[ddacosta] For 2.5 Host Metrics is off the Analytics menu. Use {MenuAAHostMetrics} -. In the navigation panel, select menu:Host Metrics[] to view the activity associated with hosts, such as those that have been automated and deleted. +. In the navigation panel, select {MenuAAHostMetrics} to view the activity associated with hosts, such as those that have been automated and deleted. + Each unique hostname is listed and sorted by the user's preference. + diff --git a/downstream/modules/platform/con-controller-minimize-administrative-accounts.adoc b/downstream/modules/platform/con-controller-minimize-administrative-accounts.adoc index c8e28195a..80d3669b8 100644 --- a/downstream/modules/platform/con-controller-minimize-administrative-accounts.adoc +++ b/downstream/modules/platform/con-controller-minimize-administrative-accounts.adoc @@ -3,11 +3,16 @@ = Minimize administrative accounts Minimizing the access to system administrative accounts is crucial for maintaining a secure system. + A system administrator or root user can access, edit, and disrupt any system application. + Limit the number of people or accounts with root access, where possible. + Do not give out _sudo_ to _root_ or _awx_ (the {ControllerName} user) to untrusted users. + Note that when restricting administrative access through mechanisms like _sudo_, restricting to a certain set of commands can still give a wide range of access. Any command that enables execution of a shell or arbitrary shell commands, or any command that can change files on the system, is equal to full root access. -With {ControllerName}, any {ControllerName} "system administrator" or "superuser" account can edit, change, and update an inventory or automation definition in {ControllerName}. +With {ControllerName}, any {ControllerName} "system administrator" or "superuser" account can edit, change, and update an inventory or automation definition in {ControllerName}. + Restrict this to the minimum set of users possible for low-level {ControllerName} configuration and disaster recovery only. diff --git a/downstream/modules/platform/con-controller-remove-access-credentials.adoc b/downstream/modules/platform/con-controller-remove-access-credentials.adoc index 24edeb0ec..ab0a415b0 100644 --- a/downstream/modules/platform/con-controller-remove-access-credentials.adoc +++ b/downstream/modules/platform/con-controller-remove-access-credentials.adoc @@ -4,4 +4,4 @@ If an {ControllerName} credential is only stored in the controller, you can further secure it. You can configure services such as OpenSSH to only permit credentials on connections from specific addresses. -Credentials used by automation can be different from credentials used by system administrators for disaster-recovery or other ad hoc management, allowing for easier auditing. +Credentials used by automation can be different from credentials used by system administrators for disaster-recovery or other ad hoc management, this makes auditing easier. diff --git a/downstream/modules/platform/con-controller-understand-architecture.adoc b/downstream/modules/platform/con-controller-understand-architecture.adoc index 7319c94cc..0cc0431b7 100644 --- a/downstream/modules/platform/con-controller-understand-architecture.adoc +++ b/downstream/modules/platform/con-controller-understand-architecture.adoc @@ -3,7 +3,7 @@ = Understand the architecture of {PlatformNameShort} and {ControllerName} {PlatformNameShort} and {ControllerName} comprise a general-purpose, declarative automation platform. -That means that once an Ansible playbook is launched (by {ControllerName}, or directly on the command line), the playbook, inventory, and credentials provided to Ansible are considered to be the source of truth. +That means that once an Ansible playbook is launched (by {ControllerName}, by {Navigator}, or directly on the command line), the playbook, inventory, and credentials provided to Ansible are considered to be the source of truth. If you want policies around external verification of specific playbook content, job definition, or inventory contents, you must complete these processes before the automation is launched, either by the {ControllerName} web UI, or the {ControllerName} API. The use of source control, branching, and mandatory code review is best practice for Ansible automation. diff --git a/downstream/modules/platform/proc-controller-api-4xx-error-config.adoc b/downstream/modules/platform/proc-controller-api-4xx-error-config.adoc index a30235e46..e7068ede1 100644 --- a/downstream/modules/platform/proc-controller-api-4xx-error-config.adoc +++ b/downstream/modules/platform/proc-controller-api-4xx-error-config.adoc @@ -14,7 +14,7 @@ These messages can be configured as required. Use the following procedure to modify the default API 4XX errors log message format. .Procedure -. From the navigation panel, select {MenuAEAdminSettings} then select *Logging settings*. +. From the navigation panel, select {MenuSetLogging}. . On the *Logging settings* page, click btn:[Edit]. . Modify the field *Log Format For API 4XX Errors*. diff --git a/downstream/modules/platform/proc-controller-authentication.adoc b/downstream/modules/platform/proc-controller-authentication.adoc index 257409cb0..32cf44767 100644 --- a/downstream/modules/platform/proc-controller-authentication.adoc +++ b/downstream/modules/platform/proc-controller-authentication.adoc @@ -7,7 +7,7 @@ Once you create and register your developer application with the appropriate ser .Procedure //[ddacosta] For 2.5, this will change to Access Management > Authentication -. From the navigation panel, select {MenuAEAdminSettings}. +. From the navigation panel, select {MenuAMAuthentication}. . Select from the following *Authentication* options: * xref:controller-set-up-azure[Azure AD settings] diff --git a/downstream/modules/platform/proc-controller-configure-jobs.adoc b/downstream/modules/platform/proc-controller-configure-jobs.adoc index b939007b6..6c73e05ca 100644 --- a/downstream/modules/platform/proc-controller-configure-jobs.adoc +++ b/downstream/modules/platform/proc-controller-configure-jobs.adoc @@ -2,14 +2,14 @@ = Configuring jobs -The *Jobs* tab enables you to configure the types of modules that can be used by the {ControllerName}'s Ad Hoc Commands feature, set limits on the number of jobs that can be scheduled, define their output size, and other details pertaining to working with jobs in {ControllerName}. +From the navigation pane, selecting *Jobs* enables you to configure the types of modules that can be used by the {ControllerName}'s Ad Hoc Commands feature, set limits on the number of jobs that can be scheduled, define their output size, and other details pertaining to working with jobs in {ControllerName}. .Procedure -. From the navigation panel, select {MenuAEAdminSettings}. -. Select *Jobs settings* in the *Jobs* option. +. From the navigation panel, select {MenuSetJob}. +. On the *Jobs settings* page, click btn:[Edit]. Set the configurable options from the fields provided. -Click the tooltip image:question_circle.png[Tool tip,15,15] icon next to the field that you need additional information about. +Click the tooltip image:question_circle.png[Tool tip,15,15] icon next to the field to provide additional information. + For more information about configuring Galaxy settings, see the link:{BaseURL}/red_hat_ansible_automation_platform/{PlatformVers}/html-single/automation_controller_user_guide/index#ref-projects-galaxy-support[Ansible Galaxy Support] section of the _{ControllerUG}_. + @@ -18,4 +18,4 @@ For more information about configuring Galaxy settings, see the link:{BaseURL}/r The values for all timeouts are in seconds. ==== + -. Click btn:[Save] to apply the settings and btn:[Cancel] to abandon the changes. +. Click btn:[Save] to apply the settings. diff --git a/downstream/modules/platform/proc-controller-configure-system.adoc b/downstream/modules/platform/proc-controller-configure-system.adoc index 1cc4ccdac..e1bf81487 100644 --- a/downstream/modules/platform/proc-controller-configure-system.adoc +++ b/downstream/modules/platform/proc-controller-configure-system.adoc @@ -2,7 +2,7 @@ = Configuring system settings -The *System* tab enables you to complete the following actions: +The *System Settings* page enables you to complete the following actions: * Define the base URL for the {ControllerName} host * Configure alerts @@ -10,29 +10,23 @@ The *System* tab enables you to complete the following actions: * Control visibility of users * Enable certain {ControllerName} features and functionality through a license file * Configure logging aggregation options +* Gather data for {Analytics} .Procedure -. From the navigation panel, select {MenuAEAdminSettings}. -. Choose from the following *System* options: -* *Miscellaneous System settings*: Enable activity streams, specify the default {ExecEnvShort}, define the base URL for the {ControllerName} host, enable {ControllerName} administration alerts, set user visibility, define analytics, specify usernames and passwords, and configure proxies. -* *Miscellaneous Authentication settings*: Configure options associated with authentication methods (built-in or SSO), sessions (timeout, number of sessions logged in, tokens), and social authentication mapping. -* *Logging settings*: Configure logging options based on the type you choose: -+ -image::ag-configure-aap-system-logging-types.png[Logging settings] -+ -For more information about each of the logging aggregation types, see the xref:assembly-controller-logging-aggregation[Logging and Aggregation] section. +. From the navigation panel, select {MenuSetSystem}. +. Click btn:[Edit]. . Set the configurable options from the fields provided. Click the tooltip image:question_circle.png[Tool tip,15,15] icon next to the field that you need additional information about. -+ -The following is an example of the *Miscellaneous System* settings: -+ -image::ag-configure-aap-system.png[Misc. system settings] -+ -[NOTE] -==== -The *Allow External Users to Create Oauth2 Tokens* setting is disabled by default. -This ensures external users cannot create their own tokens. -If you enable then disable it, any tokens created by external users in the meantime still exist, and are not automatically revoked. -==== -. Click btn:[Save] to apply the settings and btn:[Cancel] to abandon the changes. +//+ +//The following is an example of the *Miscellaneous System* settings: +//+ +//image::ag-configure-aap-system.png[Misc. system settings] +//+ +//[NOTE] +//==== +//The *Allow External Users to Create Oauth2 Tokens* setting is disabled by default. +//This ensures external users cannot create their own tokens. +//If you enable then disable it, any tokens created by external users in the meantime still exist, and are not automatically revoked. +//==== +. Click btn:[Save] to apply the settings. diff --git a/downstream/modules/platform/proc-controller-configure-usability-analytics.adoc b/downstream/modules/platform/proc-controller-configure-usability-analytics.adoc index 0e3fdfc3c..2b57a381a 100644 --- a/downstream/modules/platform/proc-controller-configure-usability-analytics.adoc +++ b/downstream/modules/platform/proc-controller-configure-usability-analytics.adoc @@ -8,18 +8,22 @@ Only users installing a trial of {PlatformName} or a fresh installation of {Cont {ControllerNameStart} collects user data automatically to help improve the product. //[ddacosta]Modified this sentence since the procedure explains how to get to the UI settings. -You can opt out or control the way {ControllerName} collects data by setting your participation level in the *User Interface settings*. +//You can opt out or control the way {ControllerName} collects data by setting your participation level in the *User Interface settings*. .Procedure -. From the navigation panel, select {MenuAEAdminSettings}. -. Select *User Interface settings* from the *User Interface* options. -. Click btn:[Edit]. -. Select the desired level of data collection from the *User Analytics Tracking State* list: -* *Off*: Prevents any data collection. -* *Anonymous*: Enables data collection without your specific user data. -* *Detailed*: Enables data collection including your specific user data. -. Click btn:[Save] to apply the settings or btn:[Cancel] to abandon the changes. +. From the navigation panel, select {MenuSetSystem}. +. On the *System Settings* page, click btn:[Edit]. +. Select the *Gather data for {Analytics}* checkbox. +. Enter the following information: +* *Last gather data for {Analytics}*: Set the date and time. +//No tool tip for the next one. This is a guess. +* *Last gathered entries from the data collection service of {Analytics}*: Enter the data and time data was last gathered. +* *{Analytics} Gather Interval*: Interval (in seconds) between data gathering. +//The following are marked with a red asterisk, it doesn't explain why. +* *Last cleanup date for HostMetrics*: Set the date and time. +* *Last computing date of HostMetricsSummaryMonthly*: Set the date and time. +. Click btn:[Save] to apply the settings. .Additional resources diff --git a/downstream/modules/platform/proc-controller-configure-user-interface.adoc b/downstream/modules/platform/proc-controller-configure-user-interface.adoc index 5382ebb85..680fb50b9 100644 --- a/downstream/modules/platform/proc-controller-configure-user-interface.adoc +++ b/downstream/modules/platform/proc-controller-configure-user-interface.adoc @@ -1,11 +1,21 @@ [id="controller-configure-user-interface"] -= Configuring the user interface += Configuring the user preferences -The *User Interface* tab enables you to set {ControllerName} analytics settings, and configure custom logos and login messages. +//The *User Interface* tab enables you to set {ControllerName} analytics settings, and configure custom logos and login messages. .Procedure -. From the navigation panel, select {MenuAEAdminSettings}. -. Select *User Interface settings* from the *User Interface* option. -. Click btn:[Edit] to configure your preferences. +. From the navigation panel, select {MenuSetUserPref}. +. You change the following settings: + +* *Refresh Interval*: Select the refresh interval for the page. +This refreshes the data on the page at the selected interval. +The refresh happens in the background and does not reload the page. +* *Color Theme*: Select from `Dark theme`, `Light theme` or `System default`. +* *Table Layout*: Select from `Comfortable` or 'Compact'. +* *Form Columns*: Select from `Multiple columns of inputs` or `Sincle column of inputs`. +* *Form Labels*: Select from `Labels above inputs` or `Labels beside inputs`. +* *Date Format*: Select from `Show dates as date and time` or 'Show date relative to the current time'. +* *Preferred Data Format*: Select from `JSON` or `YAML`. +. Click btn:[Save] to accpt your changes. \ No newline at end of file diff --git a/downstream/modules/platform/proc-controller-disabling-live-events.adoc b/downstream/modules/platform/proc-controller-disabling-live-events.adoc index 01f665df4..0698ba298 100644 --- a/downstream/modules/platform/proc-controller-disabling-live-events.adoc +++ b/downstream/modules/platform/proc-controller-disabling-live-events.adoc @@ -6,4 +6,5 @@ . Disable live streaming events by using one of the following methods: .. In the API, set `UI_LIVE_UPDATES_ENABLED` to *False*. -.. Navigate to your {ControllerName}. Open the *Miscellaneous System Settings* window. Set the *Enable Activity Stream* toggle to *Off*. +.. In the navigation panel, select {MenuSetSystem}. +.. On the *System Settings* page, clear the *Enable Activity Stream* checkbox. diff --git a/downstream/modules/platform/proc-controller-set-up-logging.adoc b/downstream/modules/platform/proc-controller-set-up-logging.adoc index 346d06ffa..43941cb4e 100644 --- a/downstream/modules/platform/proc-controller-set-up-logging.adoc +++ b/downstream/modules/platform/proc-controller-set-up-logging.adoc @@ -5,12 +5,11 @@ Use the following procedure to set up logging to any of the aggregator types. .Procedure -. From the navigation panel, select {MenuAEAdminSettings}. -. Select *Logging settings* from the list of *System* options. +. From the navigation panel, select {MenuSetLogging}. . On the *Logging settings* screen, click btn:[Edit]. . Set the following configurable options: -* *Enable External Logging*: Click the toggle button to *ON* if you want to send logs to an external log aggregator. +* *Enable External Logging*: Select the check box if you want to send logs to an external log aggregator. * *Logging Aggregator*: Enter the hostname or IP address that you want to send logs to. * *Logging Aggregator Port*: Specify the port for the aggregator if it requires one. + @@ -27,6 +26,9 @@ image:configure-controller-system-logging-types.png[Logging types] * *Logging Aggregator Username*: Enter the username of the logging aggregator if required. * *Logging Aggregator Password/Token*: Enter the password of the logging aggregator if required. +* *Loggers Sending Data to the Log Aggregator Form*: All four types of data are pre-populated by default. +Click the tooltip image:question_circle.png[Help,15,15] icon next to the field for additional information on each data type. +Delete the data types you do not want. * *Log System Tracking Facts Individually*: Click the tooltip image:question_circle.png[Help,15,15] icon for additional information, such as whether or not you want to turn it on, or leave it off by default. * *Logging Aggregator Protocol*: Click to select a connection type (protocol) to communicate with the log aggregator. Subsequent options vary depending on the selected protocol. @@ -35,17 +37,21 @@ Subsequent options vary depending on the selected protocol. This option is only applicable to HTTPS and TCP log aggregator protocols. * *Enable/disable HTTPS certificate verification*: Certificate verification is enabled by default for the HTTPS log protocol. Set the toggle to *OFF* if you do not want the log handler to verify the HTTPS certificate sent by the external log aggregator before establishing a connection. -* *Loggers to Send Data to the Log Aggregator Form*: All four types of data are pre-populated by default. -Click the tooltip image:question_circle.png[Help,15,15] icon next to the field for additional information on each data type. -Delete the data types you do not want. * *Log Format For API 4XX Errors*: Configure a specific error message. For more information, see xref:proc-controller-api-4xx-error-config[API 4XX Error Configuration]. +* *Maximum nuber of messages that can be stored in the log action queue*: Defines how large the `rsyslog` action queue can grow in number of messages stored. +This can have an impact on memory use. +When the queue reaches 75% of this number, the queue starts writing to disk. +When it reaches 90%, NOTICE, INFO, and DEBUG messages start to be discarded. +* *Minimum disk persistence for rsyslog action queueing (in GB)*: Amount of data to store (in gigabytes) if an `rsyslog` action takes time to process an incoming message (defaults to 1). +Equivalent to the `rsyslogd queue.maxdiskspace` setting on the action. +It stores files in the directory specified by `LOG_AGGREGATOR_MAX_DISK_USAGE_PATH`. . Review your entries for your chosen logging aggregation. -The following example is set up for Splunk: -+ -image:configure-controller-system-logging-splunk-example.png[Splunk logging example] +//The following example is set up for Splunk: +//+ +//image:configure-controller-system-logging-splunk-example.png[Splunk logging example] -. Click btn:[Save] or btn:[Cancel] to abandon the changes. +. Click btn:[Save]. //Following not in published version //.Verification diff --git a/downstream/modules/platform/ref-controller-capacity-instance-container.adoc b/downstream/modules/platform/ref-controller-capacity-instance-container.adoc index e368c38d8..95c5f04f9 100644 --- a/downstream/modules/platform/ref-controller-capacity-instance-container.adoc +++ b/downstream/modules/platform/ref-controller-capacity-instance-container.adoc @@ -4,11 +4,11 @@ Use the `max_concurrent_jobs` and `max_forks` settings available on instance groups to limit how many jobs and forks can be consumed across an instance group or container group. -* To calculate the `max_concurrent_jobs` you need on a container group consider the `pod_spec` setting for that container group. In the `pod_spec`, you can see the resource requests and limits for the automation job pod. Use the following equation to calculate the maximum concurrent jobs that you need: +* To calculate the `max_concurrent_jobs` required on a container group consider the `pod_spec` setting for that container group. In the `pod_spec`, you can see the resource requests and limits for the automation job pod. Use the following equation to calculate the maximum concurrent jobs that you need: ---- ((number of worker nodes in kubernetes cluster) * (CPU available on each worker)) / (CPU request on pod_spec) = maximum number of concurrent jobs ---- -** For example, if your `pod_spec` indicates that a pod will request 250 mcpu Kubernetes cluster has 1 worker node with 2 CPU, the maximum number of jobs that you need to start with is 8. +** For example, if your `pod_spec` indicates that a pod will request a 250 mcpu Kubernetes cluster that has 1 worker node with 2 CPU, the maximum number of jobs that you need to start with is 8. * You can also consider the memory consumption of the forks in the jobs. Calculate the appropriate setting of `max_forks` with the following equation: ---- ((number of worker nodes in kubernetes cluster) * (memory available on each worker)) / (memory request on pod_spec) = maximum number of forks diff --git a/downstream/modules/platform/ref-controller-capacity-planning-exercise.adoc b/downstream/modules/platform/ref-controller-capacity-planning-exercise.adoc index 7d1b5d593..82bd43359 100644 --- a/downstream/modules/platform/ref-controller-capacity-planning-exercise.adoc +++ b/downstream/modules/platform/ref-controller-capacity-planning-exercise.adoc @@ -2,7 +2,8 @@ = Example capacity planning exercise -After you have determined the workload capacity that you want to support, you must plan your deployment based on the requirements of the workload. To help you with your deployment, review the following planning exercise. +After you have determined the workload capacity that you want to support, you must plan your deployment based on the requirements of the workload. +To help you with your deployment, review the following planning exercise. For this example, the cluster must support the following capacity: diff --git a/downstream/modules/platform/ref-controller-cleanup-old-data.adoc b/downstream/modules/platform/ref-controller-cleanup-old-data.adoc index 210eaee02..1e7506ad7 100644 --- a/downstream/modules/platform/ref-controller-cleanup-old-data.adoc +++ b/downstream/modules/platform/ref-controller-cleanup-old-data.adoc @@ -17,4 +17,4 @@ This permanently deletes the job details and job output for jobs older than a sp awx-manage cleanup_activitystream [--help] ---- -This permanently deletes any link:{BaseURL}/red_hat_ansible_automation_platform/{PlatformVers}/html/automation_controller_user_guide/assembly-controller-user-interface#proc-controller-activity-stream[Activity stream] data older than a specific number of days. \ No newline at end of file +This permanently deletes any link:{BaseURL}/red_hat_ansible_automation_platform/{PlatformVers}/html automation_controller_user_guide/assembly-controller-user-interface#proc-controller-activity-stream[Activity stream] data older than a specific number of days. \ No newline at end of file diff --git a/downstream/modules/platform/ref-controller-internal-cluster-routing.adoc b/downstream/modules/platform/ref-controller-internal-cluster-routing.adoc index 4a6593662..2482a53d8 100644 --- a/downstream/modules/platform/ref-controller-internal-cluster-routing.adoc +++ b/downstream/modules/platform/ref-controller-internal-cluster-routing.adoc @@ -14,4 +14,4 @@ controller1 ansible_user=ec2-user ansible_host=10.10.12.11 node_type=hybrid rout * `controller1` is the inventory hostname for the {ControllerName} host. The inventory hostname is what is shown as the instance hostname in the application. This can be useful when preparing for disaster recovery scenarios where you want to use the backup/restore method to restore the cluster to a new set of hosts that have different IP addresses. In this case you can have entries in `/etc/hosts` that map these inventory hostnames to IP addresses, and you can use internal IP addresses to mitigate any DNS issues when it comes to resolving public DNS names. * `ansible_host=10.10.12.11` indicates how the installer reaches the host, which in this case is an internal IP address. This is not used outside of the installer. -* `routable_hostname=somehost.somecompany.org` indicates the hostname that is resolvable for the peers that connect to this node on the receptor mesh. Since it may cross multiple networks, we are using a hostname that will map to an IP address resolvable for the receptor peers. \ No newline at end of file +* `routable_hostname=somehost.somecompany.org` indicates the hostname that is resolvable for the peers that connect to this node on the receptor mesh. Since it may cross multiple networks, we are using a hostname that maps to an IP address resolvable for the receptor peers. \ No newline at end of file diff --git a/downstream/modules/platform/ref-controller-loggers.adoc b/downstream/modules/platform/ref-controller-loggers.adoc index 27a8e89d8..a5b10b872 100644 --- a/downstream/modules/platform/ref-controller-loggers.adoc +++ b/downstream/modules/platform/ref-controller-loggers.adoc @@ -15,4 +15,4 @@ These loggers only use the log-level of `INFO`, except for the `awx` logger, whi Additionally, the standard {ControllerName} logs are deliverable through this same mechanism. It should be apparent how to enable or disable each of these five sources of data without manipulating a complex dictionary in your local settings file, and how to adjust the log-level consumed from the standard {ControllerName} logs. -From the navigation panel, select {MenuAEAdminSettings}. Then select *Logging settings* from the list of *System* options to configure the logging components in {ControllerName}. +From the navigation panel, select {MenuSetLogging}. You can configure the logging components in the *Logging settings* page. diff --git a/downstream/modules/platform/ref-controller-logs.adoc b/downstream/modules/platform/ref-controller-logs.adoc index badc54ac3..0bfc7c111 100644 --- a/downstream/modules/platform/ref-controller-logs.adoc +++ b/downstream/modules/platform/ref-controller-logs.adoc @@ -6,4 +6,8 @@ This logger also includes the common fields in xref:ref-controller-log-message-s In addition, this contains a `msg` field with the log message. Errors contain a separate `traceback` field. -From the navigation panel, select {MenuAEAdminSettings}. Then select *Logging settings* from the list of *System* options and use the `ENABLE EXTERNAL LOGGING` option to enable or disable the logging components. + +.Procedure +. From the navigation panel, select {MenuSetLogging}. +. Click btn:[Edit]. +. Select `ENABLE EXTERNAL LOGGING` to enable or disable the logging components. diff --git a/downstream/modules/platform/ref-controller-node-types.adoc b/downstream/modules/platform/ref-controller-node-types.adoc index 0b62d7050..2aa792e52 100644 --- a/downstream/modules/platform/ref-controller-node-types.adoc +++ b/downstream/modules/platform/ref-controller-node-types.adoc @@ -8,3 +8,8 @@ You can configure four types of nodes in an {ControllerName} deployment: * Hybrid nodes * Execution nodes * Hop nodes + +However, in an operator-based installation, there are no hybrid or control nodes. +There are container groups, which make up containers running on the Kubernetes cluster. +That comprises the control plane. +That control plane is local to the kubernetes cluster in which {PlatformName} is deployed. diff --git a/downstream/modules/platform/ref-controller-settings-scheduling-jobs.adoc b/downstream/modules/platform/ref-controller-settings-scheduling-jobs.adoc index d03dadd82..f3b06211e 100644 --- a/downstream/modules/platform/ref-controller-settings-scheduling-jobs.adoc +++ b/downstream/modules/platform/ref-controller-settings-scheduling-jobs.adoc @@ -2,7 +2,7 @@ = Settings for scheduling jobs -The task manager periodically collects tasks that need to be scheduled and determines what instances have capacity and are eligible for running them. The task manager has the following workflow: +The task manager periodically collects tasks that must be scheduled and determines which instances have capacity and are eligible for running them. The task manager has the following workflow: . Find and assign the control and execution instances. . Update the job's status to waiting. diff --git a/downstream/modules/platform/ref-controller-workload-characteristics.adoc b/downstream/modules/platform/ref-controller-workload-characteristics.adoc index 65dc88a44..e88171d9e 100644 --- a/downstream/modules/platform/ref-controller-workload-characteristics.adoc +++ b/downstream/modules/platform/ref-controller-workload-characteristics.adoc @@ -2,11 +2,13 @@ = Characteristics of your workload -Before planning your deployment, establish the workload that you want to support. Consider the following factors to characterize an {ControllerName} workload: +Before planning your deployment, establish the workload that you want to support. +Consider the following factors to characterize an {ControllerName} workload: * Managed hosts * Tasks per hour per host * Maximum number of concurrent jobs that you want to support -* Maximum number of forks set on jobs. Forks determine the number of hosts that a job acts on concurrently. +* Maximum number of forks set on jobs. +Forks determine the number of hosts that a job acts on concurrently. * Maximum API requests per second * Node size that you prefer to deploy (CPU/Memory/Disk) diff --git a/downstream/modules/platform/ref-projects-collections-support.adoc b/downstream/modules/platform/ref-projects-collections-support.adoc index 7654d620d..02b70697a 100644 --- a/downstream/modules/platform/ref-projects-collections-support.adoc +++ b/downstream/modules/platform/ref-projects-collections-support.adoc @@ -6,8 +6,7 @@ If you specify a collections requirements file in the SCM at `collections/requirements.yml`, {ControllerName} installs collections in that file in the implicit project synchronization before a job run. {ControllerNameStart} has a system-wide setting that enables collections to be dynamically downloaded from the `collections/requirements.yml` file for SCM projects. -You can turn off this setting in the *Job Settings* screen from the navigation panel {MenuSetJob}, by switching the *Enable Collection(s) Download* -toggle button to *Off*. +You can turn off this setting in the *Job Settings* screen from the navigation panel {MenuSetJob}, by unsetting *Enable Collection(s) Download*. //image:configure-controller-jobs-download-collections.png[Download collections] diff --git a/downstream/modules/platform/ref-ratio-control-execution.adoc b/downstream/modules/platform/ref-ratio-control-execution.adoc index 0ba5c8da1..b9bd9f802 100644 --- a/downstream/modules/platform/ref-ratio-control-execution.adoc +++ b/downstream/modules/platform/ref-ratio-control-execution.adoc @@ -2,6 +2,6 @@ = Ratio of control to execution capacity -Assuming default configuration, the maximum recommended ratio of control capacity to execution capacity is 1:5 in traditional VM deployments. This ensures that there is enough control capacity to run jobs on all the execution capacity available and process the output. Any less control capacity in relation to the execution capacity, and it would not be able to launch enough jobs to use the execution capacity. +Assuming a default configuration, the maximum recommended ratio of control capacity to execution capacity is 1:5 in traditional VM deployments. This ensures that there is enough control capacity to run jobs on all the execution capacity available and process the output. Any less control capacity in relation to the execution capacity, and it would not be able to launch enough jobs to use the execution capacity. There are cases in which you might want to modify this ratio closer to 1:1. For example, in cases where a job produces a high level of job events, reducing the amount of execution capacity in relation to the control capacity helps relieve pressure on the control nodes to process that output. diff --git a/downstream/modules/platform/ref-scaling-control-nodes.adoc b/downstream/modules/platform/ref-scaling-control-nodes.adoc index 58d777888..c6506b2f2 100644 --- a/downstream/modules/platform/ref-scaling-control-nodes.adoc +++ b/downstream/modules/platform/ref-scaling-control-nodes.adoc @@ -4,6 +4,11 @@ Control and hybrid nodes provide control capacity. They provide the ability to start jobs and process their output into the database. Every job is assigned a control node. In the default configuration, each job requires one capacity unit to control. For example, a control node with 100 capacity units can control a maximum of 100 jobs. +[NOTE] +==== +In an operator-based installation of {ControllerName}, there are no hybrid or control nodes. There are container groups, which make up containers running on the Kubernetes cluster. That comprises the control plane. That control plane is local to the kubernetes cluster in which Red Hat Ansible Automation Platform is deployed. +==== + Vertically scaling a control node by deploying a larger virtual machine with more resources increases the following capabilities of the control plane: * The number of jobs that a control node can perform control tasks for, which requires both more CPU and memory. diff --git a/downstream/modules/platform/ref-scaling-execution-nodes.adoc b/downstream/modules/platform/ref-scaling-execution-nodes.adoc index 83c25dbba..915e6e41b 100644 --- a/downstream/modules/platform/ref-scaling-execution-nodes.adoc +++ b/downstream/modules/platform/ref-scaling-execution-nodes.adoc @@ -2,10 +2,15 @@ = Benefits of scaling execution nodes +[NOTE] +==== +In an operator-based installation of {ControllerName}, there are no hybrid nodes. +==== + Execution and hybrid nodes provide execution capacity. The capacity consumed by a job is equal to the number of forks set on the job template or the number of hosts in the inventory, whichever is less, plus one additional capacity unit to account for the main ansible process. For example, a job template with the default forks value of 5 acting on an inventory with 50 hosts consumes 6 capacity units from the execution node it is assigned to. Vertically scaling an execution node by deploying a larger virtual machine with more resources provides more forks for job execution. This increases the number of concurrent jobs that an instance can run. -In general, scaling CPU alongside memory in the same proportion is recommended. Like control and hybrid nodes, there is a capacity adjustment on each execution node that you can use to align actual use with the estimation of capacity consumption that the {ControllerName} makes. By default, all nodes are set to the top of that range. If actual monitoring data reveals the node to be over-used, decreasing the capacity adjustment can help bring this in line with actual usage. +In general, scaling CPU alongside memory in the same proportion is recommended. Like control and hybrid nodes, there is a capacity adjustment on each execution node that you can use to align actual use with the estimation of capacity consumption that {ControllerName} makes. By default, all nodes are set to the top of that range. If actual monitoring data reveals the node to be over-used, decreasing the capacity adjustment can help bring this in line with actual usage. An alternative to vertically scaling execution nodes is horizontally scaling the execution plane by deploying more virtual machines to be execution nodes. Because horizontally scaling can provide additional isolation of workloads, you can assign different instances to different instance groups. You can then assign these instance groups to organizations, inventories, or job templates. For example, you can configure an instance group that can only be used for running jobs against a certain Inventory. In this scenario, by horizontally scaling the execution plane, you can ensure that lower-priority jobs do not block higher-priority jobs